Опыт использования BTRFS

То есть sync вернул ок, а данные не записаны?

Типа того.

И где то железо было куплено?

Не в курсе.

Зачем нужна надёжность без целостности данных? В чём ценность файловой системы как таковой?

А в чем ценность драйверов накопителей как таковых?

Не в курсе

Используй проверенные места

Повреждение фс или носителя - крайне редкое дело

Дело в том, что если у вас btrf, то частота таких случаев резко возрастает: Помогите! Файловая система доступна только для чтения: /home - btrfs

А как у btrfs с восстановоением случайно удалённого? Чтобы как в fat - легко, быстро и без пердолинга. Есть сейчас такая фс вообще?

Есть сейчас такая фс вообще?

NilFS2

Что то мне подсказывает, что такое и с ext4 можно найти, если поискать.

Анонимус выше всё правильно написал.

Какая-то она заброшенная.

Я использовал BTRFS. Вот это её сжатие очень понравилось, особенно, если SSD, но не из самых быстрых. До сих пор помню ощущение, что программы в первый раз после загрузки запускаются быстрее. Субволюмы и особые резервные копии не заценил, ибо не использовал.

Был баг в ядре, из-за которого при наличии BTRFS начало свопинга клинило систему намертво. Были сплетни, что наличие btrfs-progs не дает Убунте спать в своп. В новых ядрах баг исправлен, Убунту в своп не спит и без btrfs-progs.

Сейчас у меня Kubuntu на ext4, ибо лень.

Я от btrfs пока (?) отказался: Долгое монтирование btrfs раздела.

у меня сегодня btrfs внезапно подключилась только на чтение. установке три дня всего. чувствую огребу еще проблем с ней, зря выбрал при установке (это на арче)

Системы с F2FS под рукой не нашлось для сравнения?

Системы с F2FS под рукой не нашлось для сравнения?

Нет.

Если бы не эффективные инлайнинг, сжатие и дедупликация, я бы ни с чем кроме ext4 вообще не заигрывал.

инлайнинг

Это то, что ещё в ReiserFS 3 было (но рекомендовалось отключать)?

Почитал немного, увидел, что в btrfs есть вроде интересная фича, DUP, для хранения файлов, которые не хочется терять, на не очень надёжных носителях. Типа многих современных microSD карточек и USB флешек. Ценой половины ёмкости, но иногда лучше так.

Ещё почитал, пишут, что сейчас ext4 умеет inline

https://unix.stackexchange.com/questions/197633/how-to-use-the-new-ext4-inline-data-feature-storing-data-directly-in-the-inod

Да, это была визитная карточка ReiserFS.
Упаковка хвостов на некоторых наборах данных даёт 50% уменьшение занимаемого пространства.
Вот пример, как 121Гб превратился в 61Гб:

btrfs как кроссплатформенная замена ntfs (комментарий)

Секрет в 16,5 млн файлов, которые удалось упаковать. Каждый такой инлайн в ext4 дал бы +4кб.

Посмотрим на более-менее типичный корень:

root@optiplex:/home/aidaho# compsize --one-file-system /
Processed 541826 files, 387954 regular extents (471710 refs), 258238 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       65%       19G          29G          30G
none       100%       14G          14G          14G
zstd        31%      4.6G          14G          15G

Там дебиан, несжимаемые базы данных, хомяк гостевого юзера.
Разбор по цифрам: ~9.5Гб редукции принесла компрессия, ~1.5Гб дедупликация.
Но на ext4 это хозяйство заняло бы не как по рефам, там ещё 258к инлайнов. То есть ~+1Гб.

Итого, то что на btrfs съело 19Гб, на ext4 без инлайнов возьмёт 31Гб.
В моём debian 10 у ext4 поддержки инлайнов ещё нет, и надо ФС пересоздавать.

Почитал немного, увидел, что в btrfs есть вроде интересная фича, DUP, для хранения файлов, которые не хочется терять, на не очень надёжных носителях. Типа многих современных microSD карточек и USB флешек. Ценой половины ёмкости, но иногда лучше так.

Только фишка в том, что на флешках, SSD и прочих устройствах с FTL DUP бесполезен, т. к. обе копии записываются одновременно, и вне зависимости от того, где они лежат в логическом адресном пространстве, во флеш-памяти они окажутся рядом. Соответственно, если что-то и вылетит, то с огромной вероятностью заденет сразу же обе копии.

Это фича против битрота и битых секторов на жёстких дисках.

Кстати я тут с удивлением обнаружил, что

$ systemctl status mnt-data.mount                                  
● mnt-data.mount - /mnt/data
     Loaded: loaded (/etc/fstab; generated)
     Active: active (mounted) since Sat 2020-11-28 21:45:01 MSK; 4 days ago
      Where: /mnt/data
       What: /dev/mapper/storage5
       Docs: man:fstab(5)
             man:systemd-fstab-generator(8)
         IP: 0B in, 0B out
         IO: 321.5M read, 229.0M written
      Tasks: 0 (limit: 47579)
     Memory: 1.6M
        CPU: 244ms
     CGroup: /system.slice/mnt-data.mount

ноя 28 21:44:14 anystation systemd[1]: Mounting /mnt/data...
ноя 28 21:45:01 anystation systemd[1]: Mounted /mnt/data.

Данных примерно как раз 10 ТБ. Два диска в RAID1. Но мне пофиг, потому что это сервер и он всё равно перезагружается пять минут :)

на разных видах raid оно у меня эпично тормозило для 2 ссд

Читал отзывы, что реально помогает.

Проблем море, профиты околонулевые. sync фейковый == велкам потеря данных и битые данные. Любая ошибка фс == полный звездец. Тебе оно надо? Если тебе нужны фичи то ставь ибо у тебя вариантв нет. Если тебе не нужны фичи, то зачем? EXT4 вылизана до блеска, надёжна и живуча.

ZFS

Ты про то, что монтирование заняло 45 секунд? Ну, значит я не один такой.

Если тебе нужны фичи то ставь ибо у тебя вариантв нет

Варианты всегда есть. Также вылизанные до блеска, кстати.

Тема оказалась противоречивой, останусь на ext4 на какое-то время.

Тема всегда будет противоречивой, это ЛОР.

Спросишь «стоит ли переходить дорогу на зелёный свет» — всё равно срач на 10 страниц будет.

Значит мне повезло: вышло всего на две.

останусь на ext4 на какое-то время

правильное решение, если не хочешь проблем, в которых ты же сам и окажешься виноватым.

Я тут тоже раздумываю на что переехать с ext4, пока решил что лучше всего LVM thin provisioning + XFS. В перспективе - замена LVM на Stratis, но пока в нём не хватает фич.

пока решил что лучше всего LVM thin provisioning + XFS

Какую задачу ты решил решать тонкими томами?

Я хочу в виртуалки пробрасывать блочные устройства для околонативного перформанса, а XFS нельзя ресайзить в меньшую сторону. С LVM-thin можно двигать партиции хоть онлайн.

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

год потыкай палкой, напиши сюда атчод :)

я не собираюсь рисковать, а машины, на которой можно потестить, у меня нет.

а машины, на которой можно потестить, у меня нет

ну так зоведи :)

Дай денег - заведу!

Все у вас «дай!» Как дети :) Компы, как свободу или деньги, не дают, а берут.

Гений, а как ты узнаешь, что данные похерелись? Без чексум-то? Тут скорее дело в том, что на днофс ты данные просрёшь и не узнаешь об этом. А вот на btrfs узнаешь.

Кстати, сижу на btrfs с момента её появления. Это более 5 лет точно. Никогда ничего не просиралось. Единственная проблема btrfs - это она безбожно тормозит на hdd. Хотя hdd нужно только для файлопомйки и там в какие-то тормоза упирается всё крайне редко. Лучше быть уверенным, что у тебя всей файлы целы.

На ssd проблем вообще нет.

не дают, а берут.

Берут, когда дают.

Безусловно только отбирают. Ну, или сами создают.

На ssd проблем вообще нет.

На SSD вместо явных тормозов CPU spikes. Но это общая болячка всех сильно фрагментированных CoW ФС.

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

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

Тем временем все жесткие диски записывают данные с чексуммами.

Это ничего не меняет. Во-первых нет никаких механизмов поднятия этих ошибок наверх, и то если они есть. Во-вторых это не более чем «кукареку». Ну и «жесткие диски» туда же.

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

Настолько «нет», что ядро ругается даже без существования лишних абстракций в виде файловой системы.

Во-вторых это не более чем «кукареку».

Такое «кукареку», что на этом основывается сохранность (целостность) данных на дисках.

А вот эти «божественные чексуммы» на файловых системах - это больше про то, чтобы сами файловые системы не попортили свои же данные. Защита от самих себя, от своей кривизны.

Кстати, сижу на btrfs с момента её появления. Это более 5 лет точно. Никогда ничего не просиралось

У нас целый чатик пересел на btrfs и у ВСЕХ оно рано или поздно умерло. Только у меня - на трех машинах.

Гений, а как ты узнаешь, что данные похерелись? Без чексум-то?

Очень просто: без хардварных проблем ничего там просто не херится, в отличие от btrfs.

Тут скорее дело в том, что на днофс ты данные просрёшь и не узнаешь об этом.

При хардварных проблемах - узнаешь и там, и там.

Без хардварных проблем - на ext4 не похерится.

Без хардварных проблем - на btrfs похерится

Лучше быть уверенным, что у тебя всей файлы целы.

Лучше быть уверенным, что на ровном месте с твоими файлами ничего не произойдет

Единственная проблема btrfs - это она безбожно тормозит на hdd

На ssd она тоже дикий тормоз, особенно с «возрастом».

Короче, ждем bcachefs

У нас целый чатик пересел на btrfs и у ВСЕХ оно рано или поздно умерло. Только у меня - на трех машинах.

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

Очень просто: без хардварных проблем ничего там просто не херится, в отличие от btrfs.

Эти фантазии. Эти фанатики с верой и методичкой. Множество раз такое было.

При хардварных проблемах - узнаешь и там, и там.

Какой жопой ты собрался узнать?

Без хардварных проблем - на ext4 не похерится.

Ещё раз, фанатик, откуда ты знаешь, что у тебя ничего не похерилось?

Без хардварных проблем - на btrfs похерится

Ну ты поподробнее расскажи об этом. Без «кукарека», а конкретно. Что сделал, что сломалось.

Лучше быть уверенным, что на ровном месте с твоими файлами ничего не произойдет

Уверенным в чём? Ты этого проверить не можешь. К тому же произойдёт, там в этом дерьме нет даже намёка транзакционность.

На ssd она тоже дикий тормоз, особенно с «возрастом».

Ога, только почему-то у меня там по 50 терабайт+/год пишется в течении нескольких лет на одну ФС. Причём это компиляция/гента и прочая мелочёвка.

А тут васян, у которого и 10% это нагрузки нет рассказывает про «упадёт», «деградация» и прочее кукареку. Меньше пропаганды жри и больше аргументации предоставляй.

Настолько «нет», что ядро ругается даже без существования лишних абстракций в виде файловой системы.

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

Такое «кукареку», что на этом основывается сохранность (целостность) данных на дисках.

Нет, не основывается. То, что где-то услышал вскукарек про коррекцию ошибок - тебе это никак не поможет и ничего не значит. Ты просто трепло, которое повторяет херню, даже не понимая что это и как работает.

Кстати, как-то странно у дошколят их кукарекалка работает. То вдруг проверки ненужны, то вот он же на них ссылается.

По поводу самих проверок. Диск не может не вернуть данные. Коррекция ошибок/всякое избыточное кордирование спасёт от пары скакнувших бит.

А вот эти «божественные чексуммы» на файловых системах - это больше про то, чтобы сами файловые системы не попортили свои же данные. Защита от самих себя, от своей кривизны.

Опять же очередная нелепая херня. Никакие чексуммы не спасают от порчи данных. И к тому же никакой жопой фс не может попортить свои данные «немного». Это не физический уровень, где может что-то «скакнуть». Здесь логические ошибки, которые херят всё. И прежде всего не данные, а их организацию внутри ФС.

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

Слышь, эксперт про кукарекам!

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

В «твоей файловой системе» короткие хеши блоков не могут обнаружить все возможные ошибки. Короткие по сравнению с размером блока - 32 бита для блока на 4 КБ ~= 32000 бит, или 0.1%.

В то время в дисковый сектор на 512 байт данных имеет около 50 байт на коррекцию ошибок, это 10%.

Я не эксперт, цифры примерно того же порядка.

Вот и подумай, на что способны «твои божественные чексуммы» по сравнению с тем, чем занимается настоящее рабочее железо.

больше аргументации предоставляй.

Оно и без деградации чуть ли не в 2 раза медленней ext4:

• https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=1

• https://www.ctrl.blog/entry/btrfs-vs-ext4-performance.html

As a btrfs volume ages, its performance may degrade.

Короче, нужно вручную отключать cow для всяких кешей, логов, БД и прочего.

Take care to keep a minimum of 10GB of free space per volume, at all times.

Отличная статья, только что вспомнил, что один из btrfs-дисков у меня как раз умер из-за 100% наполнения. Стабильность-надежность, ага.

Ну и от полного набора don’ts проиграл.

Причём это компиляция/гента и прочая мелочёвка.

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

больше аргументации предоставляй.

Тебе того желаю, короче. Заметь, ты тут один такой, у которого все Д’Артаньяны, а btrfs стабилен.

Есть и проблемы: btrfs очень чувствительна к глючному железу, теряющему записи при потере питания. Если у тебя такое — btrfs имеет все шансы развалиться.

Другими словами, на ноуте использовать не имеет смысла.