Re: Снова о ZFS
*** Sergey Matveev [2018-01-16 00:15]: >https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk >Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен >для использования зашифрованным dataset-ам. Статья устарела. В https://youtu.be/frnLiXclAMo где точно актуальный разработчик они L2ARC уже шифруют. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
18.01.2018 22:02, Sergey Matveev пишет: > *** artiom [2018-01-18 21:53]: >> А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была? > > Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых, > меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам > это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если > оно не сильно забито, существенно быстрее происходит чем обычного > RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком > диске -- он по сути делает последовательное полное чтение с одного диска > и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт > его последние актуальные данные и ссинхронизирует только diff. Если диск > не был в зеркале, то зальёт на него только полезную нагрузку > (терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут > записаны на зеркало). В-четвёртых, если данные испортились на каком-либо > из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно > известно где данные корректные и он их восстановит на втором > (self-healing типа). > Стойте, вопрос-то в другом был. С пулом всё и так ясно (кроме шифрования). Вопрос был про служебные и системные носители. Короче, позже проработаю схему и опишу. Как-то непросто получается.
Re: Снова о ZFS
*** artiom [2018-01-18 21:53]: >А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была? Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых, меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если оно не сильно забито, существенно быстрее происходит чем обычного RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком диске -- он по сути делает последовательное полное чтение с одного диска и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт его последние актуальные данные и ссинхронизирует только diff. Если диск не был в зеркале, то зальёт на него только полезную нагрузку (терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут записаны на зеркало). В-четвёртых, если данные испортились на каком-либо из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно известно где данные корректные и он их восстановит на втором (self-healing типа). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
Хотя, вроде не так всё плохо. Взял две SSD на 256 ГБ (меньше не было): - Samsung 850 PRO (http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850pro/) - Micron MTFDDAK256TBN-1AR1ZABYY (https://market.yandex.ru/product--micron-mtfddak256tbn-1ar1zabyy/1721921626) Micron - TLC 3D, Samsung Pro - некий 3D V-NAND (хотя, есть подозрение, что это тоже самое). Ну и под L2ARC остаётся Samsung Evo. Сильно плохо? 16.01.2018 14:43, Dmitry Kulagin пишет: > >>> Это, кстати, очень странное замечание, я думал, что мы уже давно живем >>> во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за >>> исключением счетного числа сломанных дисков), так что энергонезависимый >>> кеш на запись для программного рейда давно не нужен... >>> >> Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. >> > Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД > хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на > запись по умолчанию, в режим только кеш на чтение она может переводиться > только > в аппаратных рейд контроллерах, потому как остальным ОС это не надо, > они пользуются командами сброса кеша в энергонезависимую память > для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD > диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - > это непрерывный коммит, и кеш в такой ситуации не в состоянии > что-либо ускорить. А потери данных при перебое питания, которые > обсуждаются по ссылке будут всегда, вопрос только в том, что при > неадекватной > поддержке "WRITE BARRIERS" в firmware накопителей, Вам после каждого > перебоя > питания придется делать проверку файловой системы. > И фича сброса кеш памяти она, насколько я помню, не фича пользовательского > и корпоративного, или ССД и НЖМД сегмента, - это часть спецификации SATA-2 > (ну и SATA-3 и SAS, который вроде это изначально поддерживал еще со > времен SCSI) > и ее должны поддерживать все продающиеся сейчас накопители. > Насчет NVMe SSD не уверен, но думаю там должен быть аналог... >
Re: Снова о ZFS
> >>> Это, кстати, очень странное замечание, я думал, что мы уже давно живем >>> во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за >>> исключением счетного числа сломанных дисков), так что энергонезависимый >>> кеш на запись для программного рейда давно не нужен... >>> >> Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. >> > Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД > хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на > запись по умолчанию, в режим только кеш на чтение она может переводиться > только > в аппаратных рейд контроллерах, потому как остальным ОС это не надо, > они пользуются командами сброса кеша в энергонезависимую память > для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD > диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - > это непрерывный коммит, и кеш в такой ситуации не в состоянии > что-либо ускорить. Блин, я похоже, херню сделал: спрашивал сегодня SLC/TLC вместо MLC (почему-то из этого коммента всё наоборот запомнилось).
Re: Снова о ZFS
16.01.2018 11:25, Sergey Matveev пишет: > *** artiom [2018-01-16 08:37]: >> - Либо я использую ZFS шифрование и теряю L2ARC (т.е. часть >> производительности). >> - Либо я использую Gely, усложняю систему и теряю часть возможностей и >> производительности ZFS. > > Ну насчёт заметной потери (чтобы об этом можно было думать) > производительности не уверен, ну а так да -- всё верно. > >> - Докупаю 2x100 Гб (достаточно 50 Гб или не стоит жадничать?) в зеркало. >> - На них делаю два раздела поверх gely: OS и ZIL. >> - SSD на 250 Гб отвожу под L2ARC (корзина на 2.5" забита, там три диска >> всего). >> - На SAS делаю Gely слой (предполагается, что все диско-специфичные >> ioctl будут проброшены вниз, но так ли это?). >> - Организую из 4-х SAS ZRAID1 (достаточно ли 1, а не 2?). > > Раз ZIL в зеркале, то вопрос надёжности снят. > > По поводу ioctl ничего не могу сказать, не задавался этим вопросом. > > RAIDZ какого уровня это tradeoff между кол-ом дисков сколько могут > вылететь, IOPS-ами, потерянным местом -- можно и 1, можно и 2. В > домашних условиях сервер же будет под "присмотром" -- поэтому вылет > диска будет обнаружен во вменяемое время и заменён для resilver-а. > > Не забыть что и ZIL и L2ARC разделы тоже надо поверх GELI сделать. Я > кстати L2ARC делаю поверх раздела зашифрованного одноразовым ключом > (geli onetime gpt/SSDCACHE ; zpool add storage cache gpt/SSDCACHE.eli): > после перезагрузки он конечно всё "потеряет", но зато ключи нигде не > надо хранить и загружать. > А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была?
Re: тормоза ZFS
On 01/18/18 12:37, Sergey Matveev wrote: > вытесняют. ZFS может тупить например на секунды, допустим десятки секунд > -- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется > что это кто-то сторонний что-то начинает делать. Спасибо. Буду очень внимательно думать в эту сторону. Собственно, то, что это проделки ZFS, я предположил из-за того, что в такие моменты в iotop лидируют именно его процессы (хотя и не только они, но остальные каждый раз разные, а они всегда), о чем забыл упомянуть сразу. Тем не менее, раз такое поведение только у меня, значит, буду искать.
Re: тормоза ZFS
*** Alex Kicelew [2018-01-17 23:13]: >Поэтому может кто-нибудь (возможно, Sergey Matveev:) >знает, можно ли как-нибудь понять, за каким чертом он минут 5-15 читает >диск. Ух, даже не знаю что тут сказать. Вообще не могу предположить что именно ZFS мог бы делать. В фоне на долго ZFS обычно может делать только три вещи, как правило: scrub, resilver и destroy (когда async_destroy включен). На чтение из них только scrub работает. Но ARC сам по себе не будет просто так брать и освобождаться -- аналогично кэшу обычной ФС (cached поле в top/free). ARC уменьшиться в размерах только если какое-то приложение хочет памяти больше чем осталось -- тогда его вытесняют. ZFS может тупить например на секунды, допустим десятки секунд -- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется что это кто-то сторонний что-то начинает делать. Я не мало работал на системах с 4, 8 и 16 GB памяти и везде с HDD. 4 GB отличаются только тем, что по-умолчанию отключен read prefetch (но он ничего не может сделать чтобы система на минуты уходила "тупить"). Нагрузки были самые разные: и sequential read/write больших файлов и PostgreSQL с десятками GB БД и MongoDB которые упирались в IOPS диска. Но везде FreeBSD/HardenedBSD. Так что может быть это какие-то косяки в Linux реализации? Хотя коллега с GNU/Linux говорит что у него на 4 GB с HDD ни разу ничего похожего на ваше поведение не встречалось. Но мне кажется что это не в ZFS дело, раз размер ARC уменьшается -- его значит кто-то другой вытесняет. Можно попробовать например кэшировать только метаинформацию в ARC, возможно только для заданных dataset-ов, выставив zfs set primarycache=metadata. Не исключено что data регулярно вытесняет metadata и диск вынужден снова и снова лезть за ней на диск. Но это мысли в слух. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
