продолжение тут Диски для домашнего NAS. Парковка головок.
Итак диски куплены, парковка головок настроена. Осталось правильно разметить и/или создать файловую систему.
Современные диски могут иметь физический размер сектора в 512 байт (таких всё меньше) и в 4096 байт (=4К) и таких всё больше. Для дисков с физическим размером сектора 4K предложен маркетинговый термин Advanced Format (AF).
На сегодня проблема многократно описана и полностью адресована. Для большинства файловых систем достаточно разбить диски так, чтобы каждый раздел начинался с целого числа 4K секторов. Что современные версии операционных систем делают автоматически. Эту часть мы пересказывать не будем, но сосредоточимся на особенностях использования 4K дисков с файловой системой ZFS. Которая активно используется как в промышленных системах хранения, так и в домашних NAS (См. NAS своими руками ч 10 - зачем ZFS дома).
Подробнее.
1. В чем же проблема, ведь ZFS поддерживает диски с 4K сектором с 2006 г, задолго до того, как они появились на рынке?
У диска есть два параметра - логический размер сектора и физический. На сегодня все модели 4K дисков сообщают о 512 байт логическом секторе. Это сделано для совместимости с унаследованным ПО, прежде всего из Windows мира. А вот по поводу размера физического сектора единообразия нет. Первые модели сплошь сообщали о 512 секторе. Сегодня всё большее моделей, сообщающих действительный размер сектора. В результате у компьютера нет достоверного способа узнать размер физического сектора диска и этот размер ему следует сообщить.
Можно ли создать zfs пул на дисках без учёта физического 4K сектора? Можно, и даже будет вполне пристойно работать. Но производительность несколько упадёт, а нагрузка на диск увеличится. Прежде всего потому, что для записи одного 512 сектора понадобится прочитать 4K сектор, заменить содержимое одного из 512б блоков и записать результат. Это намного дольше, чем запись 4K сектора, так как придется ждать целый оборот диска.
В реальности запись одиночного сектора встречается не так часто, тк zfs стремится оптимизировать ввод-вывод за счёт кеширования. И падение производительности зависит от набора файлов. В целом - мельче файлы - больше деградация производительности.
2. Как сообщить размер сектора - зависит от ОС.
Прим. в nas4free и подобных сборках достаточно поставить галочку напротив 4K в вебгуе.
FreeBSD использует т.н. "gnop-трюк".
UPD от 21 июля 2016 Начиная со FreeBSD 10.x gnop трюк потерял актуальность. Теперь диски по умолчанию понимаются как имеющие 4K сектор. Это задаётся параметром vfs.zfs.min_auto_ashift. Его значение по умолчанию теперь равно 12, что соответсвует 4K дискам. Параметр может быть переопределён,
# sysctl vfs.zfs.min_auto_ashift=величина
/UPD
Поверх диска создаётся фиктивное устройство с 4K сектором:
gnop create -S 4096 /dev/da0
Пул создаётся с использованием такого устройства
zpool create -m /mnt/Pool Pool raidz /dev/da0.nop /dev/da1 /dev/da2
Заметим, что хотя обычно gnop-устройство рекомендуют создавать поверх каждого из используемых дисков, на самом деле достаточно чтобы один диск сообщал о своем 4K секторе, как в примере выше.
Затем пул экспортируем, разрушаем фиктивное устройство, импортируем пул
zpool export Pool
gnop destroy /dev/da0.nop
zpool import -d Pool
Прим. Аналогично, но чуть сложнее, создаётся пул на gpt разделах 4K дисков. В этом случае сначала создаются выровненные разделы. Подробнее см. в FAQ нашей конференции п. 2.4.1
В Linux реализован специальный параметр
zpool create -o ashift=12 tank
В Illumos в файл sd.conf добавляется параметр с указанием размера сектора для диска.
sd-config-list = "VENDOR PRODUCT", physical-block-size:4096;
Как проверить результат?
zdb Pool | grep ashift
число 12 соответсвует 4K сектору, число 9 - 512-байтному.
3. Недостатки, действительные и мнимые.
- теряется место. Действительно, больший размер сектора ведет к потерям на 1 файл в размере (4096-512)/2= 1792 байта. Но это малые доли процента. Потери на метаданные несколько больше, но всё равно составляют на реальных файлах доли процента.
- хуже компрессия. Действительно, если файл имеет размер 4K - компрессия будет нулевой. Для файла 8K - в лучшем случае 50%. Но неформальный тест показывает, что даже на фотографиях потери незначительны.