а Мгци и оперативы ты тоже линейкой вымеряеш?

бля, ну сколько можно то, нужно хранить 200Тб, ну купи ты 400, а лучше 800 и не нищебродствуй, мы можем и Пб

Просто так впустую?

что значит впустую, если ты их не юзаеш, то это вовсе не значит что они не нужны

20% это когда пул в гигабайты. На 1тб и далее - единицы процентов

не мешайте человеку хейтить

вот был бы он троллем, то попросил бы большие фалы поудалять :)

Интересно, проводились ли в последнее время какие-нибудь глобальные версусы btrfs vs zfs. Не так чтобы школьник на своём супернасе кладовочном говнобенч запустил, а какой-нибудь нэтфликс в своей мега лабе пару месяцов гонял петабайты.

Всё что я знаю это разрабы btrfs пока что тупо не замотивированы стабильностью и пилят новые фичи. По этому балом правит zfs.

нэтфликс же на ufs сидит, не?

они unmapped io делали для себя

И про скорость записи при заполнении в 90-95% пула

А где она не проседает?

нэтфликс же на ufs сидит, не?

А archive.org на zfs... и?

20% это когда пул в гигабайты. На 1тб и далее - единицы процентов

Нет. И зависит от объёма записи и фрагментации.

А где она не проседает?

Везде, где есть перезапись

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

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

Откуда вот это "только добавляются"?

Частный случай.

Например.

Спасибо. А какие варианты вы предлагаете? Вот надо хранить ~ 200тб и не хочется иметь болтающиеся 20% впустую

И сколько vdev в таком пуле? Фрагментация будет заключаться в раскидывании по разным vdev, что только плюс...

Апдейт в бд - это перезапись

И сколько vdev в таком пуле? Фрагментация будет заключаться в раскидывании по разным vdev, что только плюс...

1

И сколько vdev в таком пуле? Фрагментация будет заключаться в раскидывании по разным vdev, что только плюс...

Эээээ... А что именно будет раскидываться по vdev и как это поможет борьбе с фрагментацией?

Начнем с того а чем вообще фрагментация мешает

тем, что делает из последовательного чтения случайное

Апдейт в бд - это перезапись

В применении к БД да. Нужно хорошо подумать. Это касается любых умных ФС. Ибо зачастую дублируют функционал, создавая оверхэд. Но песни при про хорошую запись при полном диске, увольте. Ни ufs ни ext ни zfs эту проблему не решили.

тем, что делает из последовательного чтения случайное

Последовательное чтение в БД? Это какая то очень особенная бд....

Последовательное чтение в БД? Это какая то очень особенная бд....

Любая lsm бд

тем, что делает из последовательного чтения случайное

Именно

А смысл хранить бэкапы на том же диске? Диск навернётся и все бэкапы потеряны будут. К тому же, насколько я понимаю, снапшот - это не непосредственно данные, а информация о неком состоянии фс в момент создания снапшота, т.е. он не содержит реальных данных.

Снапшоты не бэкап

Но их можно отправлять на удалённую машину

И это уже будет бэкап))

Из снаршота разве можно восстановить данные на пустой диск?

*снапшота

Ну да. Zfs send отправит точную копию ФС.

Понял, поизучаю вопрос, спасибо.

у снапшотов самое ценное - это скорость из создания и дельты между ними.

Мгновенный откат ещё)

нэтфликс же на ufs сидит, не?

Нетфликс построен по модели внешней избыточности. Дополнительная локальная избыточность(zfs) им не к чему. Есть такое вот мнение.

Есть старый доклад от integros про ZFS на rubsd2014

Нет. И зависит от объёма записи и фрагментации.

Объём не роляет, фрагментация НА ЗАПИСЬ (при наличии места) тоже. Не надо нестю хню, если не в теме. А когда из-за места просадка, то она в десятки раз сразу, порой до 1мб/с

А смысл хранить бэкапы на том же диске? Диск навернётся и все бэкапы потеряны будут. К тому же, насколько я понимаю, снапшот - это не непосредственно данные, а информация о неком состоянии фс в момент создания снапшота, т.е. он не содержит реальных данных.

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

Но это не бэкап, пока не будет вынесено наружу

Объём не роляет, фрагментация НА ЗАПИСЬ (при наличии места) тоже. Не надо нестю хню, если не в теме. А когда из-за места просадка, то она в десятки раз сразу, порой до 1мб/с

>фрагментация НА ЗАПИСЬ с чего бы вдруг? когда у тебя свободные блоки равномерно размазаны по диску - хочешь сказать, что это никак не будет аффектить запись(и, тем более, перезапись) ?

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

снапшот содержит набор блоков определённой ревизии(на момент создания снапшота). пустые блоки он не хранит, пустые блоки живут в space maps.

>фрагментация НА ЗАПИСЬ с чего бы вдруг? когда у тебя свободные блоки равномерно размазаны по диску - хочешь сказать, что это никак не будет аффектить запись(и, тем более, перезапись) ?

Нет, там для записи выбирается единый блок, и именно поэтому когда места мало, запись такая медленная

Нет, там для записи выбирается единый блок, и именно поэтому когда места мало, запись такая медленная

Какой еще единый блок? У zfs переменный размер блока. Да, в space map блоки отсортированы по оффсету, но причем тут это?

Ну например при работе с базой или с виртуалкой часто уменьшают размер блока.

Ок, блоки подряд

Почему?

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

Есть нюансы.

Запись 64k данных 8k блоками это всё-таки 15 IO ops а не одна.

И любое изменение в файле — это запись в блок который лежит в другом месте. Только свежезаписанные файлы могут лежать кучкой, Изменяемые файлы очень быстро размазываются по диску. Особенно если ещё и снепшоты.

16к для innodb

Оракл best practics

Хз на сколько это актуально

Match ZFS recordsize with Innodb page size (16KB for Datafiles, and 128KB for Innodb log files).Howzfs set recordsize=16k tank/db Why. The biggest boost in performance can be obtained by matching the ZFS record size with the size of the IO. Since a Innodb Page is 16KB in size, most read IO is of size 16KB (except for some prefetch IO which can get coalesced). The default recordsize for ZFS is 128KB. The mismatch between the read size and the ZFS recordsize can result in severely inflated IO. If you issue a 16KB read and the data is not already there in the ARC, you have to read 128KB of data to get it. ZFS cannot do a small read because the checksum is calculated for the whole block and you have to read it all to verify data integrity. The other reason to match the IO size and the ZFS recordsize is the read-modify-write penalty. With a ZFS recordsize of 128KB, When Innodb modifies a page, if the zfs record is not already in memory, it needs to be read in from the disk and modified before writing to disk. This increases the IO latency significantly. Luckily matching the ZFS recordsize with the IO size removes all the problems mentioned above. For Innodb log file, the writes are usually sequential and varying in size. By using ZFS recordsize of 128KB you amortize the cost of read-modify-write. Note You need to set the recordsize before creating the database files. If you have already created the files, you need to copy the files to get the new recordsize. You can use the stat(2) command to check the recordsize (look for IO Block:)

Иногда просто везёт. Под виндой MSSQL по умолчанию умеет работать с базой екстентами по 64k.

И любое изменение в файле — это запись в блок который лежит в другом месте. Только свежезаписанные файлы могут лежать кучкой, Изменяемые файлы очень быстро размазываются по диску. Особенно если ещё и снепшоты.

Именно.

Так ZFS'ина фрагается даже при добавлении файлов, а не перезаписи их )

Об этом был уже эпичный срачик в FB, где приходили всякие растопырепальчатые мальчики, и сливались )

Так ZFS'ина фрагается даже при добавлении файлов, а не перезаписи их )

Ну, там есть кое-какие механизмы против фрагментации, но по факту нужен полноценный дефраг

Сейчас единственный вариант - это скопировать и удалить

Да хоть против анальных абортов, какая разница. Суть в том, что неофиты думают, наивно, что фрагается она лишь при перезаписи

это не так, неофиты )

Нууу, она по дизайну такая :(

ERROR: S client not available

Так ZFS'ина фрагается даже при добавлении файлов, а не перезаписи их )

т.е. просто алгоритм размещения блоков такой?

Бля, а так ли страшно на самом деле? Есть бенчмарк?, одни бла бла.

Бля, а так ли страшно на самом деле? Есть бенчмарк?, одни бла бла.

Нет

Не страшно )

Бля, а так ли страшно на самом деле? Есть бенчмарк?, одни бла бла.

Вот именно. Одни блаблабла

Не страшно )

на домашней файлопомойке - нет, не страшно.

веб-серверы гоняли на zfs, тоже было не страшно. FastVPS гонял петабайтные объёмы (правда zfs on linux), тоже не жаловались

веб-серверы гоняли на zfs, тоже было не страшно. FastVPS гонял петабайтные объёмы (правда zfs on linux), тоже не жаловались

>FastVPS "заебись, если хранить бэкапы и не выпендрваться по части пифоманса)"

это ответ от их бывшего cto

а мне он ответил "в целом нареканий не было"

ни слова про "ААА МЕДЛЕННО"

а мне он ответил "в целом нареканий не было"

ну, сильно зависит от сценарий использования же

так-то zil+l2arc на ссд его могут знатно ускорить то, что в лине через bcache и прочие костыли, там часть фс

чтобы запись не тормозила - ставим zil на ссд-рейд и наслаждаемся

так-то zil+l2arc на ссд его могут знатно ускорить то, что в лине через bcache и прочие костыли, там часть фс

ты сравнивал l2arc и bcache?

юзал оба

горячее подключение/замена в зфс приятнее

юзал оба

под какой сценарий?

мускуль, веб

я сранивал в контексте хранения нескольких млн мелких файлов. bcache оказался лучше чем l2arc. потому что l2arc заполнял ssd и потом начиналась игра в вытеснение с падением hit ratio

Опять рага со своими прохладными историями :)

Опять рага со своими прохладными историями :)

нуу... у меня есть пруфы )

https://www.youtube.com/watch?v=htPOOWB7yHo

Да понятно, просто годы идут, а твоя история про zfs не перестает радовать своей новизной

Да понятно, просто годы идут, а твоя история про zfs не перестает радовать своей новизной

скорее не так. годы идут, а неофиты пищат от zfs ))

И всё же. Btrfs допилили или нет? Оффтопик, но всё же.

Смотря до чего

И всё же. Btrfs допилили или нет? Оффтопик, но всё же.

Я юзаю давненько, у кого-то оно крашится

я сранивал в контексте хранения нескольких млн мелких файлов. bcache оказался лучше чем l2arc. потому что l2arc заполнял ssd и потом начиналась игра в вытеснение с падением hit ratio

В теории L2 A. R. C. — кручи

Ибо оно Adaptive Replacement Cache, а не просто банальное LRU

Самая большая шняга ZFS — жручесть памяти. Ну и то, что под Linux её, как бы, нет ;-P

Как как раз есть, как бе.