Исходное сообщение
"Началось тестирование сборок FreeBSD, переведённых на ZFS on..." Отправлено PnDx, 13-Май-19 11:52
> Не предусматривает в том плане, что выключение дедупа не ведёт к уменьшению > потребления рамы. Что было дедуплицировано, то останется таковым.   Хм. В моей картине мира ОЗУ отжирается в попытке держать все хэши "под рукой". Для этой самой дедупликации (нашёл одинаковый хэш — вставь ссылку на имеющийся блок /и с вероятностью ≈10^39 для SHA256 это таки  верно/). При чтении оно отличается от случая "все блоки уникальные" только более компактным расположением данных. Постепенно рассасывающимся в процессе CoW. Я неправ? >>> Базы будете размещать, имейте в виду, что… >> Не надо этого делать. CoW + CoW = fail. > Вот за это -- спасибо.   На всякий случай, аргументированное противоположное мнение https://www.opennet.ru/openforum/vsluhforumID3/117278.html#88   Как всегда, нужно смотреть на условия применения. В описанном случае правильно спроектированный кэш в zfs даёт выигрыш больше, чем проигрыш от применения CoW. * На обратной стороне dm-cache в linux, написанный какими-то хипстерами. Мне вот например нужно "подпирать" запись на медленные шпиндели быстрыми ssd. И как это в linux сделать? >>> По поводу root-on-zfs >> Плохая идея вне солярки. Разве что для развлечения. Если хотите иметь профит, >> старайтесь обходить проблемные места. > А почему бы, собственно, и нет? zfs-снапшоты системы это всё-таки довольно удобно.   Потому что данная ФС в linux "навесная". И проблем в таком кейсе будет сравнимо с btrfs. Пример "от противного": положите на zfs swap-файл (mkswap и т.д.) и забейте как следует ОЗУ. >>> raidz >> Не иначе как продавцы "полок" разработчикам занесли. Нужно было серьёзно постараться, чтобы >> алгоритмически зафиксировать скорость не только записи, но и *чтения* с raidz. > А можно подробности? Я не имел времени разобраться, почему zfs увеличивает латентность > чтения, я просто наблюдал её и принял как данность.   Алгоритмически я не разбирал (т.к. не готов исправлять). А замеры вот: https://habr.com/ru/post/344204/   И кое-какие советы: https://habr.com/ru/post/314506/ * И да, без ECC к zfs лучше не подходить. Как к любой БД, где нет желания расстаться с данными.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Не предусматривает в том плане, что выключение дедупа не ведёт к уменьшению >> потребления рамы. Что было дедуплицировано, то останется таковым. > Хм. В моей картине мира ОЗУ отжирается в попытке держать > все хэши "под рукой". Для этой самой дедупликации (нашёл одинаковый хэш > — вставь ссылку на имеющийся блок /и с вероятностью ≈10^39 для > SHA256 это таки верно/). При чтении оно отличается от случая > "все блоки уникальные" только более компактным расположением данных. Постепенно рассасывающимся > в процессе CoW. Я неправ? >>>> Базы будете размещать, имейте в виду, что… >>> Не надо этого делать. CoW + CoW = fail. >> Вот за это -- спасибо. > На всякий случай, аргументированное противоположное мнение > https://www.opennet.ru/openforum/vsluhforumID3/117278.html#88 > Как всегда, нужно смотреть на условия применения. В описанном случае > правильно спроектированный кэш в zfs даёт выигрыш больше, чем проигрыш от > применения CoW. > * На обратной стороне dm-cache в linux, написанный какими-то хипстерами. Мне вот > например нужно "подпирать" запись на медленные шпиндели быстрыми ssd. И как > это в linux сделать? >>>> По поводу root-on-zfs >>> Плохая идея вне солярки. Разве что для развлечения. Если хотите иметь профит, >>> старайтесь обходить проблемные места. >> А почему бы, собственно, и нет? zfs-снапшоты системы это всё-таки довольно удобно. > Потому что данная ФС в linux "навесная". И проблем в > таком кейсе будет сравнимо с btrfs. > Пример "от противного": положите на zfs swap-файл (mkswap и т.д.) и забейте > как следует ОЗУ. >>>> raidz >>> Не иначе как продавцы "полок" разработчикам занесли. Нужно было серьёзно постараться, чтобы >>> алгоритмически зафиксировать скорость не только записи, но и *чтения* с raidz. >> А можно подробности? Я не имел времени разобраться, почему zfs увеличивает латентность >> чтения, я просто наблюдал её и принял как данность. > Алгоритмически я не разбирал (т.к. не готов исправлять). А замеры > вот: > https://habr.com/ru/post/344204/ > И кое-какие советы: > https://habr.com/ru/post/314506/ > * И да, без ECC к zfs лучше не подходить. Как к > любой БД, где нет желания расстаться с данными.
	Введите код, изображенный на картинке: