> не?Не, http://savagedlight.me/2012/07/15/freebsd-zfs-advanced-format/:
ZFS is smart enough to query the underlying device to see how large its sectors are, and use this information to determine the size of its dynamic-width stripes. This is all fine and dandy for as long as the hardware isn’t lying. Sadly, hardware currently lie more often than not. My drives claim to have a logical sector size of 512 bytes (ashift=9 because 2^9=512) while the physical sectors are 4Kib (ashift=12). As such, ZFS will make stripes aligned to 512 bytes. This means stripes will almost always be non-aligned, forcing the underlying device to work its magic which in turn degrades performance.
Это проблема только кривых дисков. Выравнивание разделов спокойно делается с помощью gpart. GNOP в данном случае просто костыль, который сообщает ZFS правильный размер сектора.
Хотя мне например, решение у illumos больше нравится (хотя это тоже костыль) http://wiki.illumos.org/display/illumos/ZFS+and+Advanced+For...:
Some operating systems provide a way to pass the desired ashift value to zpool invokation in some way, or even hard-code ashift=12 into a separately built zpool binary.
The illumos-gate did not, after long discussions, follow this "trivial" path. Instead, illumos-based OSes can now override the physical block (sector) size for "talking" to particular devices regardless of what they announce, by using a value configured in the sd(7d) driver. Once the device vendor and identification strings are known, the /kernel/drv/sd.conf file can be modified:
sd-config-list =
"SEAGATE ST3300657SS", "physical-block-size:4096",
"DGC RAID", "physical-block-size:4096",
"NETAPP LUN", "physical-block-size:4096";
Т.е. они конфигурируют драйвер, чтобы тот указывал нужный размер блока, а не тот, что рапортует железяка.
