ок, про разное так про разное..

если делать ashift=9 то много ио и много места теряется. Если делать ashift=12 то место то все равно теряется

Чем меньше ashift, тем меньше физического места занимает датасет с большим количеством в т.ч. маленьких файлов, просто по опыту. Дефолтный какой кстати? 9 ведь обычно?

нет понятия дефолтного, надо подбирать исходя из вводных

а есть какие-нибудь простые способы сравнить производительности zfs в разных конфигурациях? Например набор параметров для fio , для имитации основных паттернов ? Как имитировать худший случай, когда файла нет в кэше или когда при записи zil заполнился?

удали устройство кеша, потом добавь снова

без слова cache

дестрой вроде

а не ремув

глянь help к команде

меня ключит или у тебя RAID0?)

Ну в смысле нет избыточности в пуле

рисковый ты парень)

не думаю что ты прям много выиграешь, а вот проиграть можешь)

сжимаются же блоки, вроде

Случайно да)

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

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

компрессия работает в бределах блока, ресайз

про одинаковые файлы дедуп да

чем больше блок, тем лучше жмёт

это максимальный размер arc

Кто-нибудь пробовал эксперементировать с рейд-контроллерами в качестве log, например? ;) Вот валяется LSI 9271 и кучка новых 300гб SAS 2,5" винтов.... )

zfs Же не рекомендуется ставить на аппаратный raid

Еще раз... это не пул! это как бы привод, который мы подсовываем пулу в качестве log

По сути, работа происходит с кэшем контроллера, поддержанным, скажем суперконденсатором, и потом сбрасывается на зеркало из HDD. Но латенс - приличный.... должен быть....

Хочу понять насколько мысль глупая... )

а в чем принципиально отличается работа ZFS с диском в pool и дисков в log?

Принципиально отличается. )

Если вспомнить, что log не кэш и данные, записываемые на pool через него не проходят. Или я не прав?

У меня есть тестовая хранилка, на которой я мог бы опробовать эту мысль.... но вот решил сначала понять, а не тупик ли это - просто жаль тратить время... )

По сути, работа происходит с кэшем контроллера, поддержанным, скажем суперконденсатором, и потом сбрасывается на зеркало из HDD. Но латенс - приличный.... должен быть....

в журнал он же slog он же zil запись всегда последовательная вроде

и туда идут только синхронные записи

У меня есть тестовая хранилка, на которой я мог бы опробовать эту мысль.... но вот решил сначала понять, а не тупик ли это - просто жаль тратить время... )

проверьте обычным fio. Если латенси вашего устройства ниже чем обычного/простого ссд, то можно продолжить изыскания. Для SLOG чаще всего достаточно 16-32Гб

в журнал он же slog он же zil запись всегда последовательная вроде

Это все понятно. ) Не нужно пытаться разжевать мне, что такое "журнал намерений ZFS".... или как его попроще-то на русском-то назвать.... Я спросил о другом, хочу приспособить конкретную железяку, и формируемый ею "виртуальный" диск в качестве привода log из нежелания тратиться на ssd, который по сути должен быть серверного класса. Т.к. обмен будет происходить с кэшем контроллера (остальные операции по сохранению содержимого кэша на HDD - оставим за кадром) то этот обмен обещает приличную производительность и низкий латенс, полагаю что не хуже чем у одиночного SSD на шине SATA.

проверьте обычным fio. Если латенси вашего устройства ниже чем обычного/простого ссд, то можно продолжить изыскания. Для SLOG чаще всего достаточно 16-32Гб

Сергей! Спасибо! Я представляю, как все померить... ) Но я ленив... )))) Поэтому запостил сюда с целью - узнать, что может уже кто-то пробовал такой фортель? И каковы результаты... ) Получается, что нет.

если мы делаем просто миррор на двух нвме и они умирают от износа флеша - они умирают в один день, верно?

а они умирают от износа?

а они умирают от износа?

рано или поздно

если мы делаем просто миррор на двух нвме и они умирают от износа флеша - они умирают в один день, верно?

Прямо в один навряд ли, но имхо при одинаковой нагрузки умрут примерно в одно время

а они умирают от износа?

Довольно часто умирает контролер при физической нормальной памяти

рано или поздно

ну рано или поздно и солнце погаснет

серверные накопители по моему опыту имеют примерно такую же надёжность, что и материнские платы, например

серверные накопители по моему опыту имеют примерно такую же надёжность, что и материнские платы, например

это какую?

серверные накопители по моему опыту имеют примерно такую же надёжность, что и материнские платы, например

У серверной ссд TWB 5600 а у обычного 120 разница нифига не маленькая

износ nand — в smart же есть счётчики

У серверной ссд TWB 5600 а у обычного 120 разница нифига не маленькая

серверные ssd есть разные

как и десктопные

у того же самсунга проц и память одинаковые стоят, различие в прошивке и plp

Довольно часто умирает контролер при физической нормальной памяти

читал, что чаще всего дохнет прошивка или таблица трансляции

и эта смерть вероятностная

ещё некоторые производители (intel, например) балуются переводом в readonly по достижению каких-то значений счётчиков, но это совсем не выход из строя, не находите?

и достичь такого не на тестовом стенде, а в реальной жизни не так просто

это какую?

в моём опыте один выход из строя на явно больше сотни накопителей-лет

в моём опыте один выход из строя на явно больше сотни накопителей-лет

ну у меня аткой опыт и по десктопам и по серверам))

один за несколько лет))

это ещё не значит что десктопные надо ставить в сервера))

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

нужно подбирать железо под потребности)

может кто подсказать, почему инкрементальный zfs send может идти дольше, чем простой? @gmelikov

уже не первый раз сталкиваюсь

объём данных меньше, все метаданные на special, что ему надо-то?

и открытый вопрос: а диски 14Tb или ещё пуще 18Tb разве не SMR?

WD DC hc500+ серия. У самого под зфс рэйдз2 стоят 8 Тб, полёт норм

WD DC hc500+ серия. У самого под зфс рэйдз2 стоят 8 Тб, полёт норм

ага, есть такие, я как раз первые машинки собирал на HGST He 8T, а потом их купил WD и переименовал в DC HC500

нет, один блок - это один блок, нет механизма аггрегации. Т.е. если ashift=12 (4К сектор), и блок файла сжался до 1КБ, то будет занято 4К, т.к. меньше сектора записано быть не может.

и открытый вопрос: а диски 14Tb или ещё пуще 18Tb разве не SMR?

нет, далеко не все

есть ещё механизм записи совсем мелких файлов, до 300байт чтоли, они прям в мете будут храниться

может кто подсказать, почему инкрементальный zfs send может идти дольше, чем простой? @gmelikov

не рыл в эту сторону

ну прямо вот сильно медленнее

есть recodsize, а есть ashift (размер сектора?) файл пишется блоками, каждый блок состоит из целого числа секторов размером 2^ashift; и каждый блок в несжатом виде не больше recordsize (вернее почти всегда равен recordsize)

если сжатия нет, то он так и будет на диске лежать блоками размером recordsize лежать. если сжатие есть — то каждый блок независимо будет сжиматься ДО записи на диск, и на диске под него будет выделяться столько место, сколько получилось в сжатом виде (с округлением до 2^ashift, конечно)

Не так

если я правильно понял кусок данных может быть размерами от 1 блока (2^ashift) до рекордсайза.

> в один record можно записать только одну единицу вот это предположение неверное

несжатый. а сжатый может быть меньше

диск не разбит на блоки размером recordsize

если не речь про всякие базы данных, то я считаю, что да

большой recordsize имеет один (но очень существенный) недостаток: если ты изменяешь хоть один байт в записи, она целиком читается с диска и целиком пишется обратно

если это неизменяемые файлы (условно mp3) — то почему бы и нет

и чтения тоже

плюс в ARC сжатые данные могут лежать, т.е. в ARC можно впихнуть больше данных

ну и если памяти мало, то arc будет неэкономно расходоваться

большой recordsize имеет один (но очень существенный) недостаток: если ты изменяешь хоть один байт в записи, она целиком читается с диска и целиком пишется обратно

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