Как стать автором
Обновить

Комментарии 41

Обычно я начинаю немного предвзято относиться к сочетанию слов "сервер", "аппаратный рейд контроллер", "отключите кеш".
Допустим, у меня p420i на hp gen8, есть необходимые лицензии, а также массив собран в конфигурации 6х1тб 15к + ssd cache 480 gb (hp так умеет посредством самого контроллера) + 2gb cache 25/75 на самом контроллере.
Будет ли zfs заметно вкуснее для меня? Если да, то чем?

Да, 6х1тб в рейд 10, забыл указать

Быстрее не будет, это точно. У zfs есть несколько крайне важных функций, включая чексумминг данных, которые могут быть интересны для критического хранения, но в целом, zfs — это почти секта. Авторы не хотят его видеть в Linux, Linux пожимает плечами, и только отдельная группа усиленно работает над попыткой притащить одно в другое.
Да, секта свидетелей ZFS. :-)
BTRFS тоже разрабатывала секта раскольников ZFS
> Авторы не хотят его видеть в Linux, Linux пожимает плечами, и только отдельная группа усиленно работает над попыткой притащить одно в другое.
Авторы чего не хотят видеть это в linux? Авторы zfsonlinux?
Вы вообще в курсе почему ZFS долго не портировалась в Linux?
Почитайте на досуге про лицензии того и другого и суть проблем, а потом высказывайте свое «экспертное» мнение.
btrfs делалась с прицелом на замену zfs, да. В какой-то момент выдохлась, и хотя сейчас её стабильность сильно выше, чем раньше, я бы сказал, что они ещё не вышли на пик.
Насчёт того, что авторы ZFS (не путать с ZOL) не хотят в Linux — тут sfconservancy.org/blog/2016/feb/25/zfs-and-linux

К сожалению, не могу найти тред, где обсуждалась позиция Linux (комьюнити) про поддержку функций, нужных ZFS. Спор был о том, надо ли в Linux менять что-то, что сделало бы жизнь ZoL легче, и консенсус был, что если авторы ZFS не хотят в Linux, то прикладывать специальные усилия для затаскивания его туда через shim'ы и прочий технолегалайз — это идти прямо против воли авторов ZFS.
Я плохо слежу за bsd, но вот в этом треде есть несколько другие мнения на тему «не совсем так». lwn.net/Articles/777717
С точки зрения скорости работы — сложно сказать будет ли вкуснее или нет, все зависит от целого ряда факторов:
— сколько памяти будет выделяться для кеша ZFS;
— будет ли использоваться SSD кеш на обычном дисковом пуле;
— какие данные будут храниться на дисках, да это важно, так как степень сжатия этих данных будет сильно влиять на IO;

В общем, сравнивать «в лоб» — занятие абсолютно бесполезное, тем более что ZFS это не только программный контроллер дисков, а в первую очередь таки журналируемая файловая система.

Я вас понял, это действительно вопрос религии: должна ли файловая система только обеспечивать сохранность данных, или что то ещё. Для себя я ответ на вопрос услышал, большое спасибо.

Все приличные аппаратные рейды с батарейкой предоставляют полный контроль за кешированием, включая поддержку SYNCHRONIZE CACHE (10), во-вторых, сами рейды следят за батарейкой и в случае проблемы с оной выключают writeback. За многие годы я ни разу не слышал про повреждение данных из-за ребутов на рейдах с wb и батарейкой. Скорее, можно говорить, что из-за периодической проверки батарейки будут неожиданные деградации производительности (из-за включения wt на время теста).

Далее, вы не понимаете, почему многие используют 512 байт. Причина проста — для 512 байт гарантируется атомарность. Если вы сделаете запись в 4к размером на устройство, которое внутри имеет 512-байтные блоки, то если будет авария в середине, вы можете получить partial update, что почти катастрофа для большинства блочных протоколов.

Использовать или не использовать аппаратный рейд — дело предпочтений каждого админа, я его не использую так как:
— resilvering на zfs делается быстрее;
— собирать и разбирать пулы можно без перезагрузки сервера;
— не все RAID контроллеры поддерживают сложные массивы или требуются дополнительные лицензии на них;

То что у ZFS периодически возникают проблемы с WriteCache аппаратного контроллера — да бывает и да зависит от контроллера. Как-то работал с контроллером который как бы поддерживал HBA режим, но при этом при перезагрузке сервера менял их порядок, да пришлось включать аппаратный RAID.

В общем, не суть, и публикация не об этом.
Хотите использовать аппаратный RAID на ZFS — используйте, но тогда потеряете часть функционала ZFS по управлению дисками.

Что касается 512 байт — идем сюда: en.wikipedia.org/wiki/Disk_sector
И читаем:
… Newer HDDs use 4096-byte (4 KiB) sectors, which are known as the Advanced Format (AF).

Если у вас старое железо, то да, используйте ashift=9. Но я в своей работе уже не помню когда сталкивался с подобными дисками, все как-то на новом оборудовании развлекаюсь.

Кстати, про ssd cache на уровне контроллера… Есть в такой конфигурации сервер под вин, роль обычного файлового сервера. Батарейка конечно есть на контроллере. Так вот: перегруз pdu недавно привел к аварийному выключению стойки в рабочее время, т.е. интенсивность операций чтения-записи была велика. Конкретно в этой конфигурации у нас первый раз в жизни не испортились индексы на антикварном dbf от foxpro. В предыдущих аварийных ситуациях они портились всегда вообще — хлипкие создания. Я прям зауважал хп после этого...

… Я несколько раз перечитывал, пока не понял о чём речь. Дополнительный кеш на ssd-устройствах…

… Потому что у ssd есть свой кеш и большинство производителей мамой клянётся, что там батарейка и ничего не потеряется. А выключение writeback на уровне ssd превращает 15к IOPS в 400 (worst case, 4k random, fsync).
[phoinix@db01 ~]$ gstat
dT: 1.043s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0   1438    156   1419    0.4   1281  26988    0.2   18.4| mfisyspd0
    0   1483    161   1082    0.4   1322  29383    0.3   20.5| mfisyspd1
    0   2067    178   1034    0.2   1889  29234    0.2   19.4| mfisyspd2
    0   2033    144    774    0.3   1889  29234    0.2   21.4| mfisyspd3

Мне сложно сказать что у вас там во что превращается, видимо у вас своя магия…

PERC H730 Mini
4xSSD SAMSUNG 900Gb

Как увидеть сотни иопсов вместо тысяч на SSD?


  1. hdparm -W 0 /dev/sdx
  2. mkfs (по вкусу) на него.
  3. mount /mnt /dev/sdx
  4. fio --namehostname--blocksize=4k --ioengine=libaio --iodepth=32 --direct=1 --buffered=0 --fsync=1 -- rw=randwrite --filename=/mnt/test --size=1G

Ключевое тут — hdparm -W0 и --fsync=1. Даже топовые nvme'шки сваливаются с сотен kiops в жалкие полторы тысячи.

Вы уже определитесь:
>… превращает 15к IOPS в 400
или
>… сваливаются с сотен kiops в жалкие полторы тысячи

Сколько таки IOPS на SSD?

Потому как у меня на fio с Вашими параметрами выдало:

iops: min= 3313, max=19582, avg=13246.67, stdev=3838.41, samples=39

Это жалкие 13K iops или все таки далеко не 400?

P.S. На разброс особо смотреть не стоит, сервер рабочий и у него своих дел хватает помимо моих тестов.
Плохо читаете. Я говорил, что обычные ssd — в сотни, топовые nvme — в полторы тысячи (с сотен тысяч).

Ваша конфигурация — это чистые SSD или за ними там батарейка с RAM? Что про него говорит hdparm -W /dev/sdx (если это SSD) или nvme id-ctrl /dev/nvme0 (поле vwc)?
На чем тестировал, Dell R220 без дополнительного контроллера. Встроенный работает в HBA режиме.
Нету там ни батарейки на RAM.
diskinfo -t /dev/ada0
/dev/ada0
	512         	# sectorsize
	480103981056	# mediasize in bytes (447G)
	937703088   	# mediasize in sectors
	4096        	# stripesize
	0           	# stripeoffset
	930261      	# Cylinders according to firmware.
	16          	# Heads according to firmware.
	63          	# Sectors according to firmware.
	INTEL SSDSC2BB480G6R	# Disk descr.
	PHWA62960295480FGN	# Disk ident.
	Yes         	# TRIM/UNMAP support
	0           	# Rotation rate in RPM
	Not_Zoned   	# Zone Mode

Seek times:
	Full stroke:	  250 iter in   0.013101 sec =    0.052 msec
	Half stroke:	  250 iter in   0.011557 sec =    0.046 msec
	Quarter stroke:	  500 iter in   0.021420 sec =    0.043 msec
	Short forward:	  400 iter in   0.012800 sec =    0.032 msec
	Short backward:	  400 iter in   0.009990 sec =    0.025 msec
	Seq outer:	 2048 iter in   0.051259 sec =    0.025 msec
	Seq inner:	 2048 iter in   0.051538 sec =    0.025 msec

Transfer rates:
	outside:       102400 kbytes in   0.288353 sec =   355120 kbytes/sec
	middle:        102400 kbytes in   0.206200 sec =   496605 kbytes/sec
	inside:        102400 kbytes in   0.206625 sec =   495584 kbytes/sec

P.S. hdparm не дам, т.к. это не Ubuntu

Ну так вы кеш в SSD выключали или нет? Я ж говорил, что разница между


/dev/sdb:
 write-caching =  1 (on)

и


/dev/sdb:
 write-caching =  0 (off)

Разница примерно 20-30 раз.


fsync, write-through сквозь все кеши — и ssd показывают свою реальную производительность, мало затронутую фирмварными ухищрениями.


PS Судя по Rotation rate in RPM = 0, у вас с той стороны не SCSI/SATA SSD, а какое-то гибридное устройство. У обычных SSD rotation должно быть 1.

Так, видимо мы говорим о разных вещах.
Write Cache отключается на контроллере, а не на диске.
Отключать Write Cache на диске это прямо моветон.
Видимо требуется дополнительно это указать, поправлю статью.
Прочитайте что я писал:
… Потому что у ssd есть свой кеш и большинство производителей мамой клянётся, что там батарейка и ничего не потеряется. А выключение writeback на уровне ssd превращает 15к IOPS в 400 (worst case, 4k random, fsync).


А в дополнение скажу, что при работе с одним вендором после жалобы на плохую производительность под ceph'ом, их инженер сильно заинтересовался проблемой (они проигрывали самсунгам в тестах) и… они это поправили. Устроства этого вполне известного вендора стали работать ничуть не хуже самсунгов. Когда я очень удивился и мы разговорились, всё стало понятно. Они сделали «как самсунг». Как именно? Разумеется, writeback, и (что ещё веселее), trimback, т.е. асинхронный trim.

На вопрос «а что станет с устройством» они сказали, что есть конденсатор и они уверены, что успеют скинуть кеши при отключении питания.
Они скидывают кеши при:

а) Исчезновение линка на шине (sata/ssd)
б) Исчезновение ввода питания
в) Прилетающем reset на L1 по SAS/SATA/PCI-E.

При этом они _уверены_, что успеют скинуть. Но тестов на скидывание кеша у них нет.

Другими словами, это такая лотерея, причём лотерея в которой я больше верю производителям рейда. У них хоть батарейка и точно известный протокол по скидыванию горячего кеша при включении устройства (… осложняющимся тем, что диски могли к этому времени быть заменены).
Мы ушли далеко от темы, да действительно, вендоры обещают что заряда конденсатора хватит, но
Диски находятся в зеркале, то есть заряда конденсатора должно не хватить у обоих.
Мы обсуждаем сферического коня в вакууме, если да кабы.
Публикация не об этом, а о том как установить ZFS на загрузочный раздел.
Для обсуждения вопросов «ZFS pool vs. Raid Controller» тут на Habr наверняка есть отдельная ветка.
Я к тому, что верить в конденсатор и не верить в батарейку странно. То есть:

либо выключать ВСЕ кеши (тогда мы имеем гарантии записи, если только вендор SSD не *удак и не игнорирует настройки — я такое видел), и тогда наслаждаемся 400 IOPS на средней SSD,

либо я не вижу причины не любить рейды с батарейкой. Делать многотомными их смысла нет, но сделать wb-raid0 на один диск — милое дело. И SSD легче, и деньги за железку тогда не зря уплочены.
Я ни слова не сказал, что не люблю контроллеры с батарейкой.
Речь о том, что:
"… ZFS не очень хорошо работает с аппаратными RAID массивами, в частности это связано с Write cache..."
И это факт. С какими-то контроллерами хуже, с какими-то лучше. ZFS журналируемая файловая система и отдавать гарантию записи на откуп кому-то еще не хочет по понятным причинам.
И мое мнение относительно того что мне нравится, а что не нравится — фиолетово, либо будет segfault во время записи, либо нет.
Да, именно. Но почему, из всех writeback'ов, наезд только на raid-controller? Если ZFS не хочет отдавать консистентность на откуп сегфолту в чужой фирмвари, то почему тогда мы имеем влюченный writeback на SSD устройствах?
$ camcontrol identify ada0
...
media RPM             non-rotating
...
write cache                    yes	yes
...

RPM = 0 — логично, так как не крутится, с чего ему даже быть 1
А write cache диска действительно включен.
rpm=0 было зарезервировано за композитными устройствами (типа рейдов и внешних СХД с блочным интерфейсом, iscsi и т.д.), так что для SSD сделали 1.

… Я попытался найти источник… Я не прав, эта штука linux-specific (он использует rpm=1 для обозначения ssd).

По INQUIRY/EVDP ничего такого не видно (пример ниже)
Spoiler header
Unit serial number VPD page:
Unit serial number: S3R0NF0JB22312K
Device Identification VPD page:
Addressed logical unit:
designator type: vendor specific [0x0], code set: ASCII
vendor specific: S3R0NF0JB22312K
designator type: T10 vendor identification, code set: ASCII
vendor id: ATA
vendor specific: Samsung SSD 850 EVO 250GB S3R0NF0JB22312K
designator type: NAA, code set: Binary
0x5002538d42749602
ATA information VPD page:
SAT Vendor identification: linux
SAT Product identification: libata
SAT Product revision level: 3.00
Device signature indicates SATA transport
ATA command IDENTIFY DEVICE response summary:
model: Samsung SSD 850 EVO 250GB
serial number: S3R0NF0JB22312K
firmware revision: EMT03B6Q
Block limits VPD page (SBC):
Write same non-zero (WSNZ): 0
Maximum compare and write length: 0 blocks
Optimal transfer length granularity: 1 blocks
Maximum transfer length: 0 blocks
Optimal transfer length: 0 blocks
Maximum prefetch length: 0 blocks
Maximum unmap LBA count: 0
Maximum unmap block descriptor count: 0
Optimal unmap granularity: 1
Unmap granularity alignment valid: 0
Unmap granularity alignment: 0
Maximum write same length: 0x3fffc0 blocks
Maximum atomic transfer length: 0
Atomic alignment: 0
Atomic transfer length granularity: 0
Maximum atomic transfer length with atomic boundary: 0
Maximum atomic boundary size: 0
Block device characteristics VPD page (SBC):
Non-rotating medium (e.g. solid state)
Product type: Not specified
WABEREQ=0
WACEREQ=0
Nominal form factor: 2.5 inch
ZONED=0
BOCS=0
FUAB=0
VBULS=0
Logical block provisioning VPD page (SBC):
Unmap command supported (LBPU): 0
Write same (16) with unmap bit supported (LBWS): 1
Write same (10) with unmap bit supported (LBWS10): 0
Logical block provisioning read zeros (LBPRZ): 0
Anchored LBAs supported (ANC_SUP): 0
Threshold exponent: 0
Descriptor present (DP): 0
Minimum percentage: 0
Provisioning type: 0
Threshold percentage: 0


Я дополню, что автор статьи рассказывает небылицы про 512КБ сектора, путая размер с обозначением 512К дисков (т.е. для тех, кто пропустил — есть старые диски с 512 байт сектора, новые диски с 4КБ секторами и переходная модель, которая 4КБ физические сектора, но логически == 512 байт для целей совместимости со старыми ОСями).

Я думаю, это опечатка.


Кстати, его уверенность в 4k очень интересная. Я вот открыл первую попавшуюся SSD и вижу:


cat max_hw_sectors_kb
32767


https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt


max_hw_sectors_kb (RO)
----------------------
This is the maximum number of kilobytes supported in a single data transfer.

Так что, почему 4k?

512K — Да, это конечно опечатка, спасибо, исправил.

Вопрос про 4K кроме размера блока на диске находится еще в ядре Linux в котором размер блока по-умолчанию 4K.

То что некоторые диски поддерживают размер блока больше, это прекрасная новость, но что бы поддержка стала полной требуется еще немного пересобрать ядро Linux.
Ох, расскажите мне про это. Первый раз слышу про «пересборку ядра» в контексте размера блоков для блочных устройств. Я всю жизнь считал, что это определяется исключительно клиентом. Мои наблюдения за blktrace и трейсером scsi так же это подтверждали. Я что-то упустил?
Они, кстати, 512e называются, не 512k. Обозначение произошло из-за их значения «512 emulation».
Так хочется вставить картинку с троллейбусом. Написали бы хоть полслова о том, зачем это всё вообще нужно? Чтобы partition под root не отводить?
Если я напишу хоть пол слова на тему: зачем это нужно, набежит стая «хомячков» которые будут объяснять всем: зачем это не нужно.
Каждый волен сам решать, нужно это ему или нет, и если он решит, что это ему нужно то он может воспользоваться данным документом.
В любом случае, спасибо за статью. Я просто диву даюсь, что до сих пор есть настоящие мужчины в сёлах. Я, честно скажу, не осилил бы такой алгоритм и сломался бы где-то посередине. Реально — ОЧЕНЬ много действий, что доказывает ещё раз, что система zfs не то, чтобы не пригодна к эксплуатации, но ее распространение убито именно этой излишней сложностью. И по ashift — это тоже мощно. Правильно ли я понимаю, что это количество битов для сдвига, чтобы определить размер блока? А разработчики не могли сделать человеческие параметры. Ну, там ashift=4k, чтобы сразу понимать результат, а не ломать мозг?
Очень много действий только по причине того, что инсталлятор не поддерживает возможность использования ZFS.
Если вы возьмете тот же Proxmox, то установка с root ZFS у вас займет несколько кликов.
С другой стороны, что мне сильно не понравилось, что исходная инструкция в некоторых местах не корректна, и да вы бы сломались где-то в середине, причем не от усталости а от ошибки.
Однако же, данная инструкция достаточно полезна для понимания особенностей установки в целом.
RAIDZ — в части записи медленнее, так как кроме записи требуется рассчитать контрольную сумму;
RAIDZ2 — в части записи еще медленней так как требует расчета более сложных контрольных сумм;

Это — результаты замеров или вам так кажется? Суть любой WAFL-системы, не в последнюю очередь, в практической бесплатности RAIDZ2/RAID-DP/RAID-6. Нагрузкой на CPU для расчёта контрольных сум в 2019 году можно пренебречь, тем более что ZFS в любом случае контрольную сумму считает для каждого сектора всегда.

На мой вкус — использовать WAFL-систему с зеркалом — стрелять из пушки по воробьям.

RAIDZ2 — деградация по снижению производительности выше так как требует обратного перерасчета блока из контрольной суммы для 1/4 данных + поиск блока;
RAIDZ — деградация сильно больше, так как требует обратного перерасчета блока из контрольной суммы для 1/3 данных + поиск блока;

Какой «поиск блока»? Это же WAFL, сектора с одним и тем же номером из всех дисков столбца участвуют в создании контрольной суммы, никаких дополнительных seek не должно быть в общем случае.

7. Настройка swap
sync=always — всегда синхронизировать запись. Это несколько снижает производительность, но полностью гарантирует достоверность данных;

Достоверность данных в swap после некорректной перезагрузки? Зачем нам после перезагрузки предыдущий swap?
Под WAFL я имею в виду теоретическую систему размещения данных, а не только оригинальную WAFL® от NetApp®.
Спасибо. Интересная статья.
Что насчёт поддержки Trim для SSD у ZoL?
Надо ли проводить дополнительные настройки для уменьшения SSD Write Amplification на разных типах ZFS RAIDZ?
ZOL у нас сейчас в опытной эксплуатации пока, и сейчас сказать более детально по поддержке чего-либо не могу.
С одной установкой возились неделю.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории