« Rev
@ru_zfs   266
Fwd »


George
В общем не вижу проблемы предусмотреть это, зато хороший буст к перформансу пула
George
а, ну вот, если бы был аналог слог для асинхронной записи, которая потом неспешно переезжает на пул хдд - вот это было бы интересно
В таком варианте смысла мало, на хдд асинхронная запись итак сбрасывается из озу агреггированой и на максимально возможной скорости поточно, зато забить его и получить глобальные проблемы с записью - легко. Т.е. Скорость сброса на хдд - уже узкое место, "потом неспешно переезжает" в контексте zfs тоже ооочень проблематично. Только если уж полноценно говорить про tiered решения
nikolay
если он зеркало из двух - происходит. В остальных случаях все лучше
Полный бред, вы бы хоть статистику и тёр вер поизучали что ли
Alexander
Производительностью в первую очередь
Упоминали еще про риск потери данных в CEPH, в Lustre с этим лучше?
nikolay
я хостер )
и? статистику одновременных отказов ssd в мирроре приведете? вы в хостинге какие ssd ставите если не секрет?
Alexander
риск потери данных есть везде.
Таки на FAT32 больше, чем на ZFS? Вопрос в пропорциях риска.
nikolay
Таки на FAT32 больше, чем на ZFS? Вопрос в пропорциях риска.
не готов спорить, так как не знаю статистику.
Alexander
не готов спорить, так как не знаю статистику.
Да тут простая логика, в ZFS есть журнал + проверка целостности + избыточность метаданных и данных, какая еще нужна статистика?
nikolay
тут все просто - флешка с fat32 живет 10 лет, пул может развалиться из-за бага в коде на следующий день после обновления..
Alexander
тут все просто - флешка с fat32 живет 10 лет, пул может развалиться из-за бага в коде на следующий день после обновления..
Никто же не заставляет обновлять код ZFS раньше, чем через год после релиза? Код может развалиться и для FAT, если в нем накосячить. Если за 10 лет на флэшке выпадут несколько битов, вы об этом не узнаете без дополнительного софта типа хотя бы архиватора, а в ZFS узнаете сразу же!
nikolay
Никто же не заставляет обновлять код ZFS раньше, чем через год после релиза? Код может развалиться и для FAT, если в нем накосячить. Если за 10 лет на флэшке выпадут несколько битов, вы об этом не узнаете без дополнительного софта типа хотя бы архиватора, а в ZFS узнаете сразу же!
ну вот видите, вы знаете о преимуществах zfs, это отлично) если брать решения организующие кластерные хранилища (ceph) и сравнивать их с более специализированными решениями (распределенные fs), то и там и там есть свои механизмы отвечающие за доступность и избыточность данных.
nikolay
сколько я видел "флешек с фат32" которые втихую портили данные...
не буду спорить, мой пример не про надежность флешки.
Alexander
не буду спорить, мой пример не про надежность флешки.
А про неспособность FAT детектировать сбои флэшки :)
Δαρθ
максимальный, файлы меньше рекордсайза будут меньше размером
ага спс. а вот например, что показывает filefrag имеет отношение к recordsize? если recordsize это макс. блок, значит ли это что filefrag будет грубо говоря всегда показывать колво таких 128к кусков в файле? или recordsize не связан напрямую с колвом фрагментов файла (например для случая линейной записи в файл)
Aleksei
6 серверов по 12 дисков x 8Tb, raidz2, BeeGFS как раз дадут примерно 400Tb полезного места
Aleksei
ну, чуть меньше, 390Tb
Aleksei
и открытый вопрос: а диски 14Tb или ещё пуще 18Tb разве не SMR?
nikolay
А про неспособность FAT детектировать сбои флэшки :)
а про то, что все зависит от... в конце концов либо вы встретите динозавра на улице, либо нет..
Alexander
а про то, что все зависит от... в конце концов либо вы встретите динозавра на улице, либо нет..
Только один нюанс, либо вы его встретите в танке либо в костюме из еды динозавра.
Vladimir
и открытый вопрос: а диски 14Tb или ещё пуще 18Tb разве не SMR?
https://www.anandtech.com/show/12557/seagate-announces-exos-x14-a-heliumfilled-14-tb-pmr-hdd 18tb пока не знаю какие будем ставить
Aleksei
а, тогда - "да", это похоже на правду
Aleksei
а в текущих условиях, на старом железе, есть какие-нибудь метрики типа количество iops на ядро cpu и каким блоком оперирует приложение при обработке данных?
Aleksei
диски или сеть не станут узким местом?
riv
Такой логикой весь пул из ссд в один день умирает
Поставьте разные SSD, поставьте 3 SSD в mirror, в конце концов, бекап никто не отменял. Там можно не использовать special
Aleksei
это вопрос или утверждение?
Alexander
zvol Mirror 10 дисков ssd+special(nvme) + logs(ssd) по производительности есть + но вообще не большой
Alexander
использовать пока в ZFS диски NVMe вообще не целесообразно
Alexander
и экономически не выгодно)
Nick
Никто не запрещает сделать тройной миррор из разных дисков
ну я даже не знаю, а можно 1) пример нормальных моделей, чтобы не космически стоили, продавались в РФ, и были, собственно нормальными? На u.2 выбор еще как-то есть, на m.2 совсем маленький. 2) пример платформ/материнок супермикро/асрок, чтобы можно было туда вообще воткнуть столько дисков? Потому что я вижу в основном два варианта - или дохрена дисков и все сата, или 12 дисков сата + 2 нвме, или много дисков, но все еще два нвме. Исключений почти нет - все, что предполагает обычные 3.5 диски начинается с 4ю, стоит космически, и просто так в РФ не достается вообще
Nick
о, я не прав оказывается, появились SuperStorage 6019P-ACR12L+ с 4 нвме
Nick
раньше подобные были только на 2 нвме
Nick
купить такое все равно примерно нереально, мне предлагают только везти под заказ с долгой растаможкой, но допустим
Nick
вообще профита почти не будет((( протестировано
я опечатался - много данных на хдд, и специал аллок класс на нвме - профит будет
George
zvol Mirror 10 дисков ssd+special(nvme) + logs(ssd) по производительности есть + но вообще не большой
если пул на ssd, то конечно смысла меньше, я про hdd пул говорил
Nick
о, в очередной раз спрошу, пока день и тут много людей в онлайне: как лучше сетапить zfs, если почти все файлы размером 0.9 килобайта?
Nick
диски ссд/нвме, по одному, без зеркал и raidz
Nick
если делать ashift=9 то много ио и много места теряется. Если делать ashift=12 то место то все равно теряется
Владимир
ты путаешь ашифт с ресайзблоком мне кажется
Владимир
ашифт побирают не под файлы, а под размер физического блока на устройстве
Nick
а его ж без разницы какой ставить, маленький файл запишется в маленький блок
Владимир
я обычно не заморачиваюсь и ставлю ашифт 13
Nick
но zfs же не умеет много маленьких файлов писать в один ашифт? Или я что-то пропустил?
Владимир
но zfs же не умеет много маленьких файлов писать в один ашифт? Или я что-то пропустил?
ашифт подбирают не под размер файлов)), а под размер блока на устройстве))
Владимир
пните меня если я не прав)
nikolay
это вопрос или утверждение?
это гугл https://www.google.com/search?client=firefox-b-d&q=smr+disk+list
Nick
ашифт подбирают не под размер файлов)), а под размер блока на устройстве))
ну устройство говорит что его сектор 512 байт. На самом деле конечно 4к, но устройство с 512 работать умеет и делает это нормально
nikolay
ашифт подбирают не под размер файлов)), а под размер блока на устройстве))
блока? сектора наверное все же. все современные ent hdd умеют нативно в 4к phy sector size, я обычно меняю размер logical sector size на 4к и ashift=12. ashift=13 - это все же для ssd..
Nick
раз 4 значит ставь 12
а зачем вот эти фантазии за устройство, ему наверное все же виднее? Namespace 1 Formatted LBA Size: 512
nikolay
если делать ashift=9 то много ио и много места теряется. Если делать ashift=12 то место то все равно теряется
место теряется и там и там. вот тут про место есть https://forum.ixbt.com/topic.cgi?id=4:127864:3910#3910
nikolay
ну у меня как раз везде в основном NVME и SSD)
ага, тогда понятно почему 13.
Владимир
а зачем вот эти фантазии за устройство, ему наверное все же виднее? Namespace 1 Formatted LBA Size: 512
не, ему не виднее, оно пишет 512 для совместимости со старыми ОС
Владимир
в реале значение выше, обычно это определяют тестами
Владимир
ну или через гуглёж
Nick
виднее, оно intel p4510 и отлично умеет оптимизированно агрегировать записываемое так чтобы было реально без разницы
Nick
что подтверждается тестами
Владимир
круто
Nick
место теряется и там и там. вот тут про место есть https://forum.ixbt.com/topic.cgi?id=4:127864:3910#3910
это про raidz, у меня единичные диски. что процент потерь меньше при ашифт 9 и так ожидаемо.
George
если делать ashift=9 то много ио и много места теряется. Если делать ashift=12 то место то все равно теряется
> ashift=9 то много ио и много места теряется. а где при ashift 9 место теряется много?
Nick
в файловой системе в столбце доступно и свободно
Nick
я так понял что на метаданные сильно много места уходит
George
в файловой системе в столбце доступно и свободно
при ashift 9 место как раз будет эффективнее использовать, это минимальный блок которым zfs сможет писать на диск
George
но на скорости может сказаться конечно
nikolay
я в свое время много полезного по основам zfs прочитал тут -https://jrs-s.net/category/open-source/zfs/
George
в файловой системе в столбце доступно и свободно
вообще на пустой ФС эти числа на разных ashift будут идентичными. С ashift есть нюансы для raidz, если что, там по месту может больно давать
nikolay
не, ему не виднее, оно пишет 512 для совместимости со старыми ОС
счас 512n диски я думаю уже не выпускают, 512e only
nikolay
это про raidz, у меня единичные диски. что процент потерь меньше при ашифт 9 и так ожидаемо.
гм.. тогда к чему все переживания про то что special dev в мирроре из двух ssd помрет?))
Nick
гм.. тогда к чему все переживания про то что special dev в мирроре из двух ssd помрет?))
потому что это два разных обсуждения вообще про разное?
« Rev
@ru_zfs   266
Fwd »