поможете настроить? готова оплатить если сделаете чтобы также быстро было

Так что там про writeback кэш на zfs?

его нету, разрабы забыли разработать. также как и tiered storage.

@riv1329 в общем была бы рада увидеть ваши предложения - и чтобы после они в цифры бенчей зашли

Мне нужна инфа о том как сейчас сделано на bcache и что вы пробовпли на zfs и как тестируете. Я с первого раза не понял до конца, особенно про 2 кеш устройства

Я знаю, но человек ведь заявляет, что ZFS умеет так

По тому что zfs не умеет без writeback в принципе если говорить об асинхронной записи.

Кстати … кто помнит соотношение ram и l2arc? 👋может оптанами набить )))

Вы же понимаете отличие writeback кэша от slog, правда?

Вы же понимаете отличие writeback кэша от slog, правда?

Slog работает только для синхронной записи, все остальное пишется в рамках сброса транзакций на диск, у меня раз в 5 секунд

Slog работает только для синхронной записи, все остальное пишется в рамках сброса транзакций на диск, у меня раз в 5 секунд

У меня как раз в этом и была проблема. Что zfs каждые 5 секунд дергает механические диски, которые ох какие задумчивые, от силы 240MB/s выдают, а вот с bcache ситуация сильно лучше

Про 5 секунд можно поменять через параметр txg_sync

Это все понятно. Но вот когда это будет падать на механику - пиши пропало без writeback cache.

1:4 или 1:5, а дальше смотреть насколько он забивается

Mdadm делает проверки на синхронизацию и silent corruption

Враки, я специально проверял аж mdraid6 -- нихрена он не делает

Ахахахах, шутку понял, смешно

Буквально вчера был плановый check consistency на 5-м

и чо? перед этим надо было дев урандомом посрать в один из дисков, а потом вычитать все файлы и убедиться что хеши совпали.

я тоже понял. потому что у меня в куче разных инсталляций бтрфс ВООБЩЕ не сыпется. что с ней ни делаю

И начнется ребилд

То что Вы не знаете о посыпавшиеся btrfs не значит, что он не посыпался)))

к тому моменту как бкашфс достигнет стабильности тепершней бтрфс, они там уже очередной велосипед пилить будут. и только зфс останется неумеющей расширяться на доп. место на диске )))

У меня как раз в этом и была проблема. Что zfs каждые 5 секунд дергает механические диски, которые ох какие задумчивые, от силы 240MB/s выдают, а вот с bcache ситуация сильно лучше

смотрите, сейчас ситуация такая md-raid1 -> md0, к нему подключают диск Samsung PCie x8 и делаем устройство bcache0 в режиме writeback и режиме все данные идут через кэш. у zfs не удалось сделать так - чтобы было кэширования записей, ибо SLOG это не кэш.

Там типа l2 отжирает память , но я забыл - сколько , где то читал - 1 к 50 , не могу найти теперь :(((( мысль была под всю оперативку оптанов набить )))

Я на месте. Смотрите. Да, кратковременно можно повысить быстродействие сливая данные на SSD быстрее чем они пишутся на HDD. Но нюанс в том что при большом количестве клиентов хранилища, т.е. при большом количестве VM, у вас будет монотонный не прекращающийся поток и ваше SSD переполнится, тогда, возможно, скорость станет ещё меньше чем на zfs, поскольку zfs избегает случайной записи, чем увеличивает пропускную способность дисков. Тут надо отметить, что если вам не важна латентость, то наверное нагружая систему, можно получить от неё ещё бОльшую производительность. Но как правило, количество и глубину очередей как раз огрничивает латентность. По тому, почти всегда, задрав глубину очередей и их количество вы заставите устройства работать бустрее. Но из-за наличия очередей, латентность ухудшиться. Для VM за которыми работаю люди, после 50мс-70мс, люди скажут что машина тупит и далее наращивать глубину очередей нельзя. Так вот в ZFS как раз и происходит отложенный сброс данных на диск чтобы повысить пропускную способность дисков на запись, но там это не вызывает такого роста латентности, т.к. либо задействуется slog либо это не синхронный трафик, который может подождать, а в случае неожиданной перезагрузки, он будет потерян, но это не приведет к проблемам, из-за того что запись ведется транзакционно... я тут сильно не вникал, но суть в том что файловые системы не рушатся, если zfs дергать перезагрузками, в отличие от обычного тупого writwback. Я думаю, по этому, разработчики сосредоточились на таком режиме работы: мелкие блоки и метадата пишутся на SSD, синхронный трафик пишется в slog, а не синхронный пишется большими кусками раз в несколько секунд. А чтобы диски не тупили при сбросе на них крупных блоков, планировщик как-то оптимизирует это процесс, а ещё больше улучшает ситуацию со случайным чтением SSD-кэш. При нехватке iops, преполагается маштабировать их за счет: - размера кэша - количества vdev под основными данными, special и slog в зависимости от типа нагрузки. И возможно, это так-же эффективно, а может быть и боле эффективно для такого гибридного хранилища, чем создавать что-то типа bcache, у которого другие недостатки, например он наверняка в разы более сильно насилует SSD, даже супер стойкий серверный, а при долговременной нагрузке больше чем могут вывезти диски, по идее должны переполнятся SSD. Про суперстойкость. У меня сейчас на серверных накопителях после пары лет работы под базами данных, где 10% износа, где 20%. Недавно запустил одну проблемную нагрузку и она за сутки выела 1% износа на серверной SSD размером больше 1ТБ. Зато на оптайнах везде износ по 0-лям ))) Я думаю, можно не расписывать, что бытовые под такими нагрузками сразу же потеряют производительность, а через пару дней вообще подохнут. Износ SSD - это отдельная тема, замечу лишь одно, есть такие виды нагрузки, которые заставляют контроллер SSD писать в память в сотни, а то и в 1000 раз больше чем сваливается на накопитель, но возможен и обратный эффект. Подведу итог, zfs - это проверенное практикой решение, рассчитанное на большие объемы, большое количество потоков, более-менее равномерно не прекращающуюся нагрузку, которая на практике встречается часто в промышленной эксплуатации. bcache надо изучать, учиться его готовить. Я конечно, этим займусь, надо сравнить. Для меня не маловажной особенностью zfs являются ещё и снимки для тотального, быстрого и робастого бекапа.

У меня подход другой: Так как я сам администрирую VM, я просто сделал несколько пулов: HDD, SSD для системных разделолв и хардкорный optane only пул для баз данных. Ну и базы данных выношу на отдельный диск в виртуалке, который размещается на этом пуле. Но последнее время, думаю о том что, может быть и через slog на hdd попробовать... тут нужны эксперементы, которые я пока не делал. Пул на optane работает очень хорошо )))

Да slog - это не кэш. Увеличить быстродействие линейной записи на HDD можно только увеличив количество HDD VDEV. А у вас, как я понимаю, есть два Samsung PCie x8 по 1.6TB и 2 HDD по 16TB, а ещё есть SSD или HDD для того чтобы я предложил вам конфигурацию?

Нет, на 1.6ТБ он один - я же написала что есть в сервере :)

У меня подход другой: Так как я сам администрирую VM, я просто сделал несколько пулов: HDD, SSD для системных разделолв и хардкорный optane only пул для баз данных. Ну и базы данных выношу на отдельный диск в виртуалке, который размещается на этом пуле. Но последнее время, думаю о том что, может быть и через slog на hdd попробовать... тут нужны эксперементы, которые я пока не делал. Пул на optane работает очень хорошо )))

у вас же mdraid-1 - из двух таких SSD?

@riv1329 В данный момент имеем физические устройства 16TB 3.5" HDD SATA WD 7200rpm 512MB cache WUH721816ALE6L4 16TB 3.5" HDD SATA WD 7200rpm 512MB cache WUH721816ALE6L4 1.6TB AIC SSD NVMe (PCIe x8) Samsung MZPLL1T6HAJQ-00005 128GB M.2 SSD NVMe (PCIe x4) Samsung MZVLQ128HCHQ-00B00 1TB M.2 SSD NVMe (PCIe x4) Samsung уже не помню кто там стоит Сейчас собрано так md-raid1 (2 x 16TB) + 1.6TB bcache writeback -> bcache0 на bcache0 ставим zfs ashift=12 log 128GB M.2 (да да, будет и второй такой диск) special 1TB M.2 Бенчи такие fio --filename=test-r-4 --sync=0 --rw=read --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-4 --sync=0 --rw=write --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-r-16 --sync=0 --rw=read --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-16 --sync=0 --rw=write --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-r-512 --sync=0 --rw=read --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-512 --sync=0 --rw=write --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-4 --sync=0 --rw=randrw --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-16 --sync=0 --rw=randrw --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-512 --sync=0 --rw=randrw --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --name=rand_rw_4 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=4k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-4.fio" --group_reporting --direct=1 fio --name=rand_rw_16 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=16k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-16.fio" --group_reporting --direct=1 fio --name=rand_rw_512 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=512k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-512.fio" --group_reporting --direct=1 По мнению заказчика нужно тестить в 20 потоков, поскольку столько будет контейнеров на машине

Я на месте. Смотрите. Да, кратковременно можно повысить быстродействие сливая данные на SSD быстрее чем они пишутся на HDD. Но нюанс в том что при большом количестве клиентов хранилища, т.е. при большом количестве VM, у вас будет монотонный не прекращающийся поток и ваше SSD переполнится, тогда, возможно, скорость станет ещё меньше чем на zfs, поскольку zfs избегает случайной записи, чем увеличивает пропускную способность дисков. Тут надо отметить, что если вам не важна латентость, то наверное нагружая систему, можно получить от неё ещё бОльшую производительность. Но как правило, количество и глубину очередей как раз огрничивает латентность. По тому, почти всегда, задрав глубину очередей и их количество вы заставите устройства работать бустрее. Но из-за наличия очередей, латентность ухудшиться. Для VM за которыми работаю люди, после 50мс-70мс, люди скажут что машина тупит и далее наращивать глубину очередей нельзя. Так вот в ZFS как раз и происходит отложенный сброс данных на диск чтобы повысить пропускную способность дисков на запись, но там это не вызывает такого роста латентности, т.к. либо задействуется slog либо это не синхронный трафик, который может подождать, а в случае неожиданной перезагрузки, он будет потерян, но это не приведет к проблемам, из-за того что запись ведется транзакционно... я тут сильно не вникал, но суть в том что файловые системы не рушатся, если zfs дергать перезагрузками, в отличие от обычного тупого writwback. Я думаю, по этому, разработчики сосредоточились на таком режиме работы: мелкие блоки и метадата пишутся на SSD, синхронный трафик пишется в slog, а не синхронный пишется большими кусками раз в несколько секунд. А чтобы диски не тупили при сбросе на них крупных блоков, планировщик как-то оптимизирует это процесс, а ещё больше улучшает ситуацию со случайным чтением SSD-кэш. При нехватке iops, преполагается маштабировать их за счет: - размера кэша - количества vdev под основными данными, special и slog в зависимости от типа нагрузки. И возможно, это так-же эффективно, а может быть и боле эффективно для такого гибридного хранилища, чем создавать что-то типа bcache, у которого другие недостатки, например он наверняка в разы более сильно насилует SSD, даже супер стойкий серверный, а при долговременной нагрузке больше чем могут вывезти диски, по идее должны переполнятся SSD. Про суперстойкость. У меня сейчас на серверных накопителях после пары лет работы под базами данных, где 10% износа, где 20%. Недавно запустил одну проблемную нагрузку и она за сутки выела 1% износа на серверной SSD размером больше 1ТБ. Зато на оптайнах везде износ по 0-лям ))) Я думаю, можно не расписывать, что бытовые под такими нагрузками сразу же потеряют производительность, а через пару дней вообще подохнут. Износ SSD - это отдельная тема, замечу лишь одно, есть такие виды нагрузки, которые заставляют контроллер SSD писать в память в сотни, а то и в 1000 раз больше чем сваливается на накопитель, но возможен и обратный эффект. Подведу итог, zfs - это проверенное практикой решение, рассчитанное на большие объемы, большое количество потоков, более-менее равномерно не прекращающуюся нагрузку, которая на практике встречается часто в промышленной эксплуатации. bcache надо изучать, учиться его готовить. Я конечно, этим займусь, надо сравнить. Для меня не маловажной особенностью zfs являются ещё и снимки для тотального, быстрого и робастого бекапа.

Хм, я почему-то тоже был уверен, что 1.6тб - 2 штуки

Он один, я же в начале самом написала что стоит в сервере :)

@riv1329 В данный момент имеем физические устройства 16TB 3.5" HDD SATA WD 7200rpm 512MB cache WUH721816ALE6L4 16TB 3.5" HDD SATA WD 7200rpm 512MB cache WUH721816ALE6L4 1.6TB AIC SSD NVMe (PCIe x8) Samsung MZPLL1T6HAJQ-00005 128GB M.2 SSD NVMe (PCIe x4) Samsung MZVLQ128HCHQ-00B00 1TB M.2 SSD NVMe (PCIe x4) Samsung уже не помню кто там стоит Сейчас собрано так md-raid1 (2 x 16TB) + 1.6TB bcache writeback -> bcache0 на bcache0 ставим zfs ashift=12 log 128GB M.2 (да да, будет и второй такой диск) special 1TB M.2 Бенчи такие fio --filename=test-r-4 --sync=0 --rw=read --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-4 --sync=0 --rw=write --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-r-16 --sync=0 --rw=read --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-16 --sync=0 --rw=write --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-r-512 --sync=0 --rw=read --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-512 --sync=0 --rw=write --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-4 --sync=0 --rw=randrw --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-16 --sync=0 --rw=randrw --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-512 --sync=0 --rw=randrw --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --name=rand_rw_4 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=4k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-4.fio" --group_reporting --direct=1 fio --name=rand_rw_16 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=16k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-16.fio" --group_reporting --direct=1 fio --name=rand_rw_512 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=512k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-512.fio" --group_reporting --direct=1 По мнению заказчика нужно тестить в 20 потоков, поскольку столько будет контейнеров на машине

И да, Вы бы все же почитали все же про bcache прежде чем про насилия ssd, либо уточняли, что за диск у Вас дал 1% за 1 день

@riv1329 В данный момент имеем физические устройства 16TB 3.5" HDD SATA WD 7200rpm 512MB cache WUH721816ALE6L4 16TB 3.5" HDD SATA WD 7200rpm 512MB cache WUH721816ALE6L4 1.6TB AIC SSD NVMe (PCIe x8) Samsung MZPLL1T6HAJQ-00005 128GB M.2 SSD NVMe (PCIe x4) Samsung MZVLQ128HCHQ-00B00 1TB M.2 SSD NVMe (PCIe x4) Samsung уже не помню кто там стоит Сейчас собрано так md-raid1 (2 x 16TB) + 1.6TB bcache writeback -> bcache0 на bcache0 ставим zfs ashift=12 log 128GB M.2 (да да, будет и второй такой диск) special 1TB M.2 Бенчи такие fio --filename=test-r-4 --sync=0 --rw=read --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-4 --sync=0 --rw=write --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-r-16 --sync=0 --rw=read --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-16 --sync=0 --rw=write --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-r-512 --sync=0 --rw=read --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-w-512 --sync=0 --rw=write --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-4 --sync=0 --rw=randrw --bs=4k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-16 --sync=0 --rw=randrw --bs=16k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --filename=test-randrw-512 --sync=0 --rw=randrw --bs=512k --numjobs=20 --iodepth=32 --group_reporting --name=test --filesize=64G --runtime=60 fio --name=rand_rw_4 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=4k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-4.fio" --group_reporting --direct=1 fio --name=rand_rw_16 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=16k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-16.fio" --group_reporting --direct=1 fio --name=rand_rw_512 --ioengine=libaio --rw=randrw --rwmixread=50 --bs=512k --iodepth=64 --numjobs=20 --size=2G --runtime=30 --gtod_reduce=1 --filename="test-rand-rw-512.fio" --group_reporting --direct=1 По мнению заказчика нужно тестить в 20 потоков, поскольку столько будет контейнеров на машине

Это я помню, а в bcache на чем у вас SSD-буфер? на одном SSD?

Да я же не спорю с вами. Описываю как бывает. диск не самый мощный, но он стоял пару лет под нагрузкой нескольки х десятков VM под системы и некоторое количество база данных, заполненный на 80% и за 2 года ресурс выработался с 10% до 19%, а тут за день 1% от, простите сраного неудачного SQL-запроса. Конкретнее диск NVME U.2 2.5" 2400Gb MICRON Micron 9100 а тоже самое на консьюмерском optane 905P никак значимо на износ не повлияло.

Это я помню, а в bcache на чем у вас SSD-буфер? на одном SSD?

У Samsung 1.6TB AIC изностойкость где-то в 3 раза выше чем у Micron 9100 - если смотреть офф даташиты

Да я же не спорю с вами. Описываю как бывает. диск не самый мощный, но он стоял пару лет под нагрузкой нескольки х десятков VM под системы и некоторое количество база данных, заполненный на 80% и за 2 года ресурс выработался с 10% до 19%, а тут за день 1% от, простите сраного неудачного SQL-запроса. Конкретнее диск NVME U.2 2.5" 2400Gb MICRON Micron 9100 а тоже самое на консьюмерском optane 905P никак значимо на износ не повлияло.

Да я же не спорю с вами. Описываю как бывает. диск не самый мощный, но он стоял пару лет под нагрузкой нескольки х десятков VM под системы и некоторое количество база данных, заполненный на 80% и за 2 года ресурс выработался с 10% до 19%, а тут за день 1% от, простите сраного неудачного SQL-запроса. Конкретнее диск NVME U.2 2.5" 2400Gb MICRON Micron 9100 а тоже самое на консьюмерском optane 905P никак значимо на износ не повлияло.

Но диски вы поставили в зеркало, а SSD просто щитаете достаточно надёжным? но если с SSD, пусть и Samsung AIC что-то все же случится, не только по причине износа, но и просто выйдет из строя по каким-то другим причинам, при отсутствии бекапа - это не будет катастрофой? (на всякий случай, я не язвлю, просто уточняю условия задачи)

Будь моя воля - я бы поставила там общую СХД - чтобы к ней сервера подключались, но увы у меня такой возможности нету 😢 поэтому приходится искать решение из того что есть

Это я к тому, что в zfs тоже можно собрать такой конфиг: Схематично mirror hdd16TB_1 hdd16TB_2 special mirror LV_1TB_M.2_NVMe_Samsung_100GB LV_SAMSUNG_AIC_100GB slog LV_SAMSUNG_AIC_100GB cache LV_SAMSUNG_AIC_1.4TB LV_1TB_M.2_NVMe_Samsung_900GB В случае гибели SAMSUNG будет не ЖОПА, а маленькая жопка в виде подключения пула без slog, но это не фатально. Будет откат на несколько транзакций. Рекомендую посмотрить у такого конфига как будет под вашей нагрузкой? На мой взгляд это самый логичный конфиг с zfs. Ну и про lvm - не всем это понравится, но я такое использую на практике и это работает без проблем, по этому и предлагаю к рассмотрению.

Типа такого уже пробовали, проблема на записи, низкая скорость - и по бенчам что я писала - в SLA не укладываемся

По iops не укладываетесь или по скорости линейной записи?

Это все понятно. Но вот когда это будет падать на механику - пиши пропало без writeback cache.

а вот с bcache получилось уложиться

я вижу вам нравится это решение. Что ж держите нас в курсе. С zfs можно только увеличивать количество дисков: для линейной записи, можно использовать raidz1 например из 3-х или 5-ти HDD, а для рандомной несколько mirror. ещё момент, вы же не учитываете прогрев кэша, но при таком ТЗ, тут не учтешь на синтетике реалистично.

Это не называется *нравится* это называется *решение подходит под SLA*

Это я к тому, что в zfs тоже можно собрать такой конфиг: Схематично mirror hdd16TB_1 hdd16TB_2 special mirror LV_1TB_M.2_NVMe_Samsung_100GB LV_SAMSUNG_AIC_100GB slog LV_SAMSUNG_AIC_100GB cache LV_SAMSUNG_AIC_1.4TB LV_1TB_M.2_NVMe_Samsung_900GB В случае гибели SAMSUNG будет не ЖОПА, а маленькая жопка в виде подключения пула без slog, но это не фатально. Будет откат на несколько транзакций. Рекомендую посмотрить у такого конфига как будет под вашей нагрузкой? На мой взгляд это самый логичный конфиг с zfs. Ну и про lvm - не всем это понравится, но я такое использую на практике и это работает без проблем, по этому и предлагаю к рассмотрению.

я вижу вам нравится это решение. Что ж держите нас в курсе. С zfs можно только увеличивать количество дисков: для линейной записи, можно использовать raidz1 например из 3-х или 5-ти HDD, а для рандомной несколько mirror. ещё момент, вы же не учитываете прогрев кэша, но при таком ТЗ, тут не учтешь на синтетике реалистично.