Comments 18
Рассуждения выглядят убедительно, но я бы всё-таки на месте автора провёл натурный эксперимент.
Тема параметра ashift не раскрыта. И так, диски могут иметь размер физического сектора 512 байт, а могут 4 килобайта, в ZFS есть Alignment Shift (ashift=n)
The ashift property determines the block allocation size that ZFS will use per vdev (not per pool as is sometimes mistakenly thought). Ideally this value should be set to the sector size of the underlying physical device (the sector size being the smallest physical unit that can be read or written from/to that device).
Соответственно ashift=9 для 512 и ashift=12 для 4к.
Когда появились первые диски с блоком 4к, многие столкнулись с деградацией производительности. Выравнивать нужно было вручную при создании fs. Поменять ashift после создания fs было нельзя.
Всё было очень интересно, но ничего не понятно.
нужно углубиться в принципы работы ZFS
Вот вроде действительно автор углубился в эти самые принципы, но такое ощущение, что углубляться он уже начал с подлодки этак на 3-х километровой глубине… Для человека не в теме, как было нихера не понятно, так и осталось.
Нужен бы калькулятор параметров для широких масс, чтобы хоть как-то прикидывать схемы
Размер блока (или кластер ФС или блок/страница/как_там_его_еще_обозвали пишущей сущности, смотря что больше) делим на количество устройств с данными (количество устройств в vdev минус избыточность, для зеркала это всегда один, для RaidZ3 из пяти дисков это два). Если поделилось нацело — вы попали в оптимум, если нет — zfs будет делать больше записей, если меньше единицы… wake up, Neo, не стоило принимать слабительное и снотворное одновременно).
Хинт: если дисков с данными не кратно степени двойки, то нацело не поделится.
Проблема старая, и характерна и для обычных Raid5/6/x0, по тем же самым причинам: raid оперирует большими кусками, страйпами, и если страйп на диски не лезет за раз, то будет писаться за два раза, а неиспользованный остаток тупо теряется.
https://www.team.ru/RAID-IOPS-Calculator.php
Совет дам, сделайте типа такого
с Ashift и реккомендациями по доп настройкам, так же рассчетом RAM и еще что там придет в голову, круто чтобы сраз комманды внесения в sysctl
Это будет лучше 10к статей и комментариев
Такие ссылки сохраняют в избранное и ходят перед каждым
Обьсяню
ZFS полезен тем что он расширяем
Т.е я могу брать группы дисков не сразу, а по времени, скажем строя 4х дисковый RaidZ, Итого получая 50Raid
Так вот начать могу с 4 дисков, затем еще 4, и так до 16-56 дисков в корзинку
По графическому конфигуратору я смог бы прикинуть обьем получаемый, какие нужно выстроить настройски сразу для производительности, может вообще нужно брать не 1 пул по 4 диска а сразу 2-3?
Одно дело брать excel и там считать и вспоминать, другое дело вот интсрумент, на котором могу чет сообразить и вычислить не долго думая
Разглагольствования о режиме работы ZFS закончились необходимостью резиновых демпферов в корпусе.
Неплохо подсвечено как и куда копать в поиске производительности, но заканчивается еще лучше: хотите по настоящему избавиться от шума - меняйте корпус системника и ставьте резиновые уплотнители на крепления винтов.
На самом деле описано не так подробно, как могло бы показаться на первый взгляд. Вообще дурацкая идея использовать блочное устройство для файлов вместо датасета, сам я так не делаю, по этому опыта с этим у меня мало, и не уверен, что все что я скажу ниже так же относится к блочной записи, в сравнение с датасетами.
Картинки может и наглядные, но неправильные:
Четность всегда записывается перед секторами данных
На картинках отсутствуют падинги и в статье они даже не упомянуты
Характер записываемых данных так же не обозначен, а он сильно влияет на укладку данных на диски
ZIL никак не упомянут и то как его параметры влияют на укладку данных
Про падинги дерну цитату pdfvin с профильного форума:
Любая запись (четность + блок данных) для raidzN должна быть в секторах (определяется ashift) кратна (N+1). Такое решение было принято, чтобы в процессе эксплуатации в дисковом пространстве не возникали мёртвые дыры размером менше (N+1) куда нельзя записать даже блок минимального размера (это приводило бы к потере дискового пространства, хотя padding тоже приводит к потере ). Если volblocksize=8k, ashift=12, то для raidz1 имеем 1 сектор четность, 2 сектора данные. 1+2=3 не кратно 2, поэтому аллоцируем дополнительный сектор (padding).
А точно ли дело в файловой системе? Ситуация напоминает историю с 2,5" HDD от WD "неудачной" серии, у которых по умолчанию была включена частая парковка головок. Симптомы были ровно такие же, как у автора. Лечилось отключением данной функции специально утилитой. После чего жёсткий диск благополучно работал без каких-то дополнительных звуков и ощутимо меньше грелся. Один из таких HDD у меня до сих пор работает файлопомойкой в режиме 24/7 уже лет пять.
Почему мои ZFS-диски так шумят?