ZFS и диск с 4K сектором aka Advanced Format
Это окончание, начало тут Выбор дисков для домашнего NAS. Железная часть,
продолжение тут Диски для домашнего 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%. Но неформальный тест показывает, что даже на фотографиях потери незначительны.
продолжение тут Диски для домашнего 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%. Но неформальный тест показывает, что даже на фотографиях потери незначительны.