Комментарии 41
Обычно я начинаю немного предвзято относиться к сочетанию слов "сервер", "аппаратный рейд контроллер", "отключите кеш".
Допустим, у меня p420i на hp gen8, есть необходимые лицензии, а также массив собран в конфигурации 6х1тб 15к + ssd cache 480 gb (hp так умеет посредством самого контроллера) + 2gb cache 25/75 на самом контроллере.
Будет ли zfs заметно вкуснее для меня? Если да, то чем?
Да, 6х1тб в рейд 10, забыл указать
BTRFS тоже разрабатывала секта раскольников ZFS
> Авторы не хотят его видеть в Linux, Linux пожимает плечами, и только отдельная группа усиленно работает над попыткой притащить одно в другое.
Авторы чего не хотят видеть это в linux? Авторы zfsonlinux?
Вы вообще в курсе почему ZFS долго не портировалась в Linux?
Почитайте на досуге про лицензии того и другого и суть проблем, а потом высказывайте свое «экспертное» мнение.
Насчёт того, что авторы ZFS (не путать с ZOL) не хотят в Linux — тут sfconservancy.org/blog/2016/feb/25/zfs-and-linux
К сожалению, не могу найти тред, где обсуждалась позиция Linux (комьюнити) про поддержку функций, нужных ZFS. Спор был о том, надо ли в Linux менять что-то, что сделало бы жизнь ZoL легче, и консенсус был, что если авторы ZFS не хотят в Linux, то прикладывать специальные усилия для затаскивания его туда через shim'ы и прочий технолегалайз — это идти прямо против воли авторов ZFS.
www.opennet.ru/opennews/art.shtml?num=49815
Обсуждение в комментариях лучше не читать :-)
— сколько памяти будет выделяться для кеша ZFS;
— будет ли использоваться SSD кеш на обычном дисковом пуле;
— какие данные будут храниться на дисках, да это важно, так как степень сжатия этих данных будет сильно влиять на IO;
В общем, сравнивать «в лоб» — занятие абсолютно бесполезное, тем более что ZFS это не только программный контроллер дисков, а в первую очередь таки журналируемая файловая система.
Далее, вы не понимаете, почему многие используют 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 есть свой кеш и большинство производителей мамой клянётся, что там батарейка и ничего не потеряется. А выключение 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?
hdparm -W 0 /dev/sdx
- mkfs (по вкусу) на него.
- mount /mnt /dev/sdx
fio --name
hostname--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 или за ними там батарейка с RAM? Что про него говорит hdparm -W /dev/sdx (если это SSD) или nvme id-ctrl /dev/nvme0 (поле vwc)?
Нету там ни батарейки на 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 во время записи, либо нет.
$ camcontrol identify ada0
...
media RPM non-rotating
...
write cache yes yes
...
RPM = 0 — логично, так как не крутится, с чего ему даже быть 1
А write cache диска действительно включен.
… Я попытался найти источник… Я не прав, эта штука linux-specific (он использует rpm=1 для обозначения ssd).
По INQUIRY/EVDP ничего такого не видно (пример ниже)
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
Криво написал, извините. Собственно, я вот про это: https://m.habr.com/ru/company/hpe/blog/277285/
Я думаю, это опечатка.
Кстати, его уверенность в 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?
Вопрос про 4K кроме размера блока на диске находится еще в ядре Linux в котором размер блока по-умолчанию 4K.
То что некоторые диски поддерживают размер блока больше, это прекрасная новость, но что бы поддержка стала полной требуется еще немного пересобрать ядро Linux.
Каждый волен сам решать, нужно это ему или нет, и если он решит, что это ему нужно то он может воспользоваться данным документом.
Если вы возьмете тот же 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?
Что насчёт поддержки Trim для SSD у ZoL?
Надо ли проводить дополнительные настройки для уменьшения SSD Write Amplification на разных типах ZFS RAIDZ?
Ubuntu 18.04 Root on ZFS