Are those 4k drives? Yes, you can see that they report 4096 byte physical which is the indicator for this. The 512 byte logical reporting is a result of drive manufacturers' attempt at backwards compatibility (and thus confuses things).
gpart? In your situation I would use the following commands to gpart out the disk:
# -- Force ashift to be at least 12
# -- Create GPT tables
gpart create -s gpt ada0 &&
gpart create -s gpt ada1 &&
gpart create -s gpt ada2;
# -- Create paritions, align start/stop to 1 MiB boundaries
gpart add -a 1m -t freebsd-zfs -l disk0 ada0 &&
gpart add -a 1m -t freebsd-zfs -l disk1 ada1 &&
gpart add -a 1m -t freebsd-zfs -l disk2 ada2;
# -- Not needed under FreeBSD 10.1 but sometimes is on
# older versions to get /dev/gpt to update.
# Run if you don't see /dev/gpt/disk0 etc devices:
true > /dev/ada0; true > /dev/ada1; true > /dev/ada2;
# -- Create temporary GNOP 4k devices
gnop create -S 4k /dev/gpt/disk0 &&
gnop create -S 4k /dev/gpt/disk1 &&
gnop create -S 4k /dev/gpt/disk2;
# -- Create the zpool
zpool create -f -m /mnt zstorage raidz /dev/gpt/disk0.nop /dev/gpt/disk1.nop /dev/gpt/disk2.nop;
# -- Export
zpool export zroot;
# -- Remove temproary GNOP devices
gnop destroy /dev/gpt/disk0.nop &&
gnop destroy /dev/gpt/disk1.nop &&
gnop destroy /dev/gpt/disk2.nop;
# -- Bring back pool with "real" devices
zpool import -d /dev/gpt zstorage;
# -- Check status
# -- Verify ashift is 12
zdb | grep ashift
gpart-ing has no performance penalty or drawbacks that we're aware of or have seen. We have had this deployed in dozens of production locations for many, many years. It also confers the following advantages:
- You can label (the -l) partitions (i.e. disk0, disk1) so you know which disks are which, even if their port numbers change (i.e. ada0 might not always be disk0).
gpart show -l will show the GPT table with those labels.
- While not applicable to you, it lets you boot off ZFS and also have swap partitions (i.e. using GMIRROR) on the same disks.
- Due to 1 MiB alignment, you end up with a little bit of free space at the end of the disk because your partition is rounded to 1 MiB. This avoids a situation where you replace a drive with a different vendor and it ends up being ever-so-slightly smaller and thus unusable.
You'll also notice the first thing above is to do
sysctl vfs.zfs.min_auto_ashift=12; and the last thing is check that value. Under ZFS ashift=9 is the default which is appropriate for 512 byte disks but for 4k disks you'd see write amplification and loss of performance, similar in effect but not in cause due to partition misalignment. We've seen where, for unknown reasons, ZFS does not pick ashift=12 automatically even with GNOP so this forces the issue. This page describes the whole thing nicely: http://savagedlight.me/2012/07/15/freebsd-zfs-advanced-format/
Tuning? Depends on your work load. We now enable LZ4 compression on all new deployments as it has proven to have negligible overhead at worst and at best increases performance drastically for compressible files.
# -- Set compresison on
zfs set compression=lz4 zstorage;
# -- See compression performance
zfs get used,compressratio,compression,logicalused zstorage;
The only "down side" is that this will affect benchmarking,
bonnie++ will report some insane(ly awesome) numbers when this is turned on that likely don't reflect real-world performance. Same with
dd if=/dev/zero of=test.dat style benchmarking.