Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен.

Но я не проверял как работает это, тк ничего за год не упало.

С одной стороны хорошо, что не упало, с другой интересно было бы попробовать ребилд массива btrfs.

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

По каким меркам мерить это «дохрена»?

Невменоз - это пытаться втиснуть ФС 21-го века в объём архаичных накопителей, игнорируя специально для таких случаев предназначенные опции.

я честно признаюсь, всё практически делал что в btrfs что zfs особо не вникая, благо манов копи паст хватает. Мне нравится btrfs тем, что она позволяет отказываться от мемкешеда у программистов на рабочих станциях, а с ним ой как много проблем у них при разработке, btrfs значительно повышает работоспособность шар на самбе и в отличии от zfs поддерживает полностью acl.

С любым разделом.

Я уже говорил, что использую btrfs под системный раздел с его тоннами мелких файлов. Сколько раз ещё это повторить, чтобы дошло?

ты просто понимаешь какой коефициет сжатия данных где одни нули?

К чему ты вообще тут про нули?

Если делаешь rollback, то совершенно логично, что снапшоты свежее того на который орткатываемся не нужны.

что за бред?

А Шишкинские кривляния с 700-метровым разделом не выглядят по-детски?

А какое значение имеет размер партиции? Если бы он заполнил 100-гигабатник, то процент пущеного в туалет дискового пространства был бы тем же самым. Просто 100-гигабатник дольше бы заполнялся.

Если бы он заполнил 100-гигабатник, то процент пущеного в туалет дискового пространства был бы тем же самым

Продемонстрируй это.

что за бред?

Если принято решение, не по пьянке, откатиться, то для чего нужны снапшоты свежее точки отката?
Если по пьянке, то предварительно сделай clone-promote последнему снапшоту и выдели его в новую ветку, главное вспомнить с утра, зачем ты это сделал.

Продемонстрируй это

Это довольно тупая работа. Шишкин явно указал, что дамп дерева имеет «период» (см. Appendix B. https://lkml.org/lkml/2010/6/18/144 ). Ясно, что всё то же самое будет и на бОльших разделах.

5 тб данных, 6 терабайт пространства, проблем не было....

а сколько снапшотов можно насоздавать и падает ли io при создании снапшотов как у lvm?

Меня не интересует, что там у тебя. Меня интересуют проблемы, с которыми Я сталкиваюсь.

Я сейчас повторяю его феерический эксперимент на разделе в 2 гига. О результатах доложу.

падает, на 5% при создании крупных снапшотов, например снапшота проекта в 4 тб, кол-во снапшотов не считал, снапшоты делались у файлопомойки 3 раза в сутки,инкрементальный снапшот, производительность если и падала, то очень не значительно, юзвери даже не замечали. Снапшоты рабочих станций аналогично.

Если принято решение, не по пьянке, откатиться, то для чего нужны снапшоты свежее точки отката?

чтобы восстановить цепочку событий и исправить баг, из-за которого пришлось откатываться.

мониторинг сам писал или для заббикса уже есть типмлейты?

Что-то оно на 399-ой тысяче файлов начало шкрябать диском и тормозить -))

поясню, у меня у всех работников было по 2 диска, один на котором работали и второй под снапшоты, снапшоты были 2 типов, те, что делались раз в неделю полностью и сохранялись, и ежедневные, которые делались каждый день инкрементально, то есть новые данные старые затирали. За год это понадобилось 10 раз, тк часто удаляли им нужные документы...

ну и ещё из тех снепшотов можно повыдирать потом данные пользователей и перенести на рабочую систему.

я цеплял стандартный для hdd, а для проверки файловой системы делали свой(по сути с питонщиком нашим рядом посидел, сказал что надо, он сделал на 50 строк кода.) и прицепил в заббикс.

чтобы восстановить цепочку событий и исправить баг, из-за которого пришлось откатываться.

Если у тебя такой иноплантеный workflow, делай клоны с ряда снапшотов и ищи баги, откатываться то зачем?

а для проверки файловой системы делали свой

с этого места поподробнее

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

Что-то оно на 399-ой тысяче файлов начало шкрябать диском и тормозить -))

Там был какой-то фикс от Мейсона, но вся проблема в том, что проблема не ушла: btrfs начинает расползаться и показывать «no space left on device» там, где у остальных файловых систем при том же сценарии еще полно свободного места на диске.

зачем вообще нужен rollback, если никто в здравом уме его никогда не будет делать? чтобы «младший энтерпрайз админ» своими кривыми руками удалил важные данные из снепшотов?

btrfs.fsck запускался, а потом он похитрому как то его отправлял записывать в базу данных мускуля, а результат хорошо или плохо был в комплексном экране для виртуалки.

Dolphin показывает без заметных глазу задержек. Другое дело, что началось такое царапание харда, что я занервничал и пришлось перезагружаться, потому что kill -9 не помогал.

Короче, окончания теста я не дождался, по вышеупомянутым причинам. Картина такова:

locus ~ # losetup /dev/loop0 /media/mix/btrfs-image 
locus ~ # mount /dev/loop0 /mnt/temp
locus ~ # ls /mnt/temp | wc -l
398056
locus ~ # btrfs filesystem df /mnt/temp
Data, single: total=8.00MiB, used=576.00KiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1006.00MiB, used=972.70MiB
Metadata, single: total=8.00MiB, used=0.00
GlobalReserve, single: total=32.00MiB, used=0.00

Что, впрочем, неудивительно, ибо файлы упаковывались в дерево. Сейчас повторю с max_inline

Он не расползается. Он упаковывает мелкие файлы в дерево.

Да, таки дефраг починили. Прогнал на двух разделах, никаких проблем. Пропишу автодефраг в fstab на том разделе, которого не жалко (вики говорит, что эта опция будет в дефолте, когда разработчики точно убедятся, что она не запускается чаще чем надо).

его ещё починили в декабре 2013.

Я не слежу за коммитами в ядро, поэтому был не в курсе.

если никто в здравом уме его никогда не будет делать?

Делают и гораздо чаще, чем ты думаешь.

я перед сном читал твоё сообщение и мне превиделось что ты устроил тэст на запись и при этом берёшь данные из /dev/null. Прости. Надо мне больше отдыхать.

Делают и гораздо чаще, чем ты думаешь.

значит они не в здравом уме

значит они не в здравом уме

Ещё один, нашел в архитектуре zfs фатальный недостаток )

Он упаковывает мелкие файлы в дерево.

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

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

Что значит не упаковывает, если упаковывает? Лол.

Кстати, побочное знание от этого эксперимента: 12309 таки побеждён! -))

А как в ZFS?

В ZFS сжатие поблочное. Сжался первый блок или нет не оказывает никакого влияния на сжатие последующих. Если блок сжимается плохо, например если блок в 4 КБ (8 секторов) не удалось сжать до 3,5 КБ (7 секторов) или менее - он хранится без компрессии.

Блоки из нулей, кстати, при включенном сжатии превращаются во вполне себе полноценные дырки, превращая файл в sparse.

Это слишком ресурсоёмко, нафиг надо.

Эксперимент опять пришлось прервать, когда хард начал тарахтеть (жалко мне этого старичка -))

locus ~ # dd if=/dev/zero of=/media/mix/btrfs-image bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 9.74956 s, 220 MB/s
locus ~ # losetup /dev/loop0 /media/mix/btrfs-image
locus ~ # mkfs.btrfs /dev/loop0
Btrfs v3.16.1
See http://btrfs.wiki.kernel.org for more information.

Performing full device TRIM (2.00GiB) ...
Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
fs created label (null) on /dev/loop0
        nodesize 16384 leafsize 16384 sectorsize 4096 size 2.00GiB
locus ~ # mount -t btrfs -o noatime,max_inline=256 /dev/loop0 /mnt/temp
locus ~ # for i in $(seq 1000000); do dd if=/dev/zero of=/mnt/temp/file_$i bs=2048 count=1 &>/dev/null; done
^C
locus ~ # btrfs filesystem df /mnt/temp
Data, single: total=1.37GiB, used=1.37GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=310.38MiB, used=260.67MiB
Metadata, single: total=8.00MiB, used=0.00
GlobalReserve, single: total=48.00MiB, used=0.00
locus ~ # ls /mnt/temp | wc -l
511678

На мой взгляд, всё норм.

Это значит «упаковывает так, что лучше бы не упаковывал». Лол.

я уверен

Это, безусловно, очень важно.

«Лучше бы не упаковывал» реализуется опцией max_inline. Я от тебя дождусь умных аргументов?