Правильный уход за Btrfs

Треды о том, как правильно готовить btrfs напоминают такие же про КДЕ :)

В общем, классический флейм «теоретически красивое» vs «работающее».

Я бы это сказал как «теоретически работающeе» vs «практически неработающее». Не являюсь сторонником Шишкина (ты правильно заметил, что он так ничего и не родил, а трындеть - не мешки ворочать), но и btrfs называть работающим - тоже знатная шутка.

btrfs называть работающим - тоже знатная шутка

Btrfs работает, это факт. Насколько эта работа стабильна и эффективна - об этом уже можно спорить. Лично я тоже не доверяю этой ФС, хотя у меня не было с ней проблем.

Насколько эта работа стабильна и эффективна - об этом уже можно спорить

Работает = стабильна. Если нестабильна, то не работает (= в процессе разработки).

Если нестабильна, то не работает

Из этого определения следует, что работающего софта вообще не существует.

Для разного софта разные уровни стабильности. Если просмотрщик картинок падает раз в день – ну и ладно, когда-нибудь поправят. Если ФС при обычном использовании падает раз в два года – ну ее к чертям.

ФС при обычном использовании падает раз в два года

Я не знаю, что такое «обычное использование», что за сценарии и условия под этим скрываются? Я «обычно использовал» Btrfs на генте, проблем не было.

Я не знаю, что такое «обычное использование», что за сценарии и условия под этим скрываются?

Снапшоты, шифрование, сжатие. Иногда жесткое отключение. Иногда ФС забивается почти полностью. В общем, обычное использование ФС.

Я

Последняя буква в алфавите.

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

Открывашке не место на туристическом ноже, равно как и пиле. Каждый турист должен носить отделыные иструменты, делающие свою работу хорошо: нож, пилу и открывашку.

В общем, обычное использование ФС.

В общем, просто болтовня.

Открывашке не место на туристическом ноже, равно как и пиле. Каждый турист должен носить отделыные иструменты, делающие свою работу хорошо: нож, пилу и открывашку.

В данном случае это скорее попытка приделать промышленную циркулярную пилу к ножику для чистки фруктов.

Давно уже читал, нотайс про bcachefs успел забыть.

Что касается нахождения фатальных недостатков и способа их устранения – всё есть. Иначе у Кента не было бы денег и мотивации пилить свою ФС столько времени. Вот что нашёл на эту тему:

btrfs, which was supposed to be Linux’s next generation COW filesystem - Linux’s answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs.

Btrfs COW design builds on a paper from Ohad Rodeh from yeah 2007 «Shadows and clones». The COW design is different than what ZFS does, where it limits e.g. possibility of reflinks, and to my knowledge bcachefs does COW in yet another way. There’s one more filesystem I shall not name that does COW in yet another way. See? We don’t even agree on the fundamentals of simple copy on write concept, but this is fine, we’re exploring the possibilities.

https://www.reddit.com/r/btrfs/comments/13ons7x/what_precisely_does_kent_overstreet_bcachefs_mean/

И это полностью согласуется с моим опытом – то с btrfs всегда какие-то дикие проблемы вроде кернел паников и порчи всей структуры диска.

Так что пока ничего лучше ext4/xfs поверх LVM/mdraid не придумали.

И это полностью согласуется с моим опытом – то с btrfs всегда какие-то дикие проблемы вроде кернел паников и порчи всей структуры диска.

Так с этим никто не спорит. Вопрос в том, будет ли у bcachefs по другому.

вот это приходилось делать https://www.suse.com/support/kb/doc/?id=000020696

Т.е. были проблемы с удалением снапшотов при использовании квот?

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

вот и отрубил

XFS корраптится там, где другие ФС не корраптятся (см. фиксы к fs/xfs/ в любом релизе ядра). Значит ли это, что XFS сырая и к использованию не готова?

вот кстати для xfs приходилось грузиться с исошника и рекаверить с xfs_repair (на убунте), а недавно захотел включить дедупликацию на одном разделе с ней - фиг, слишком старая версия, надо пересоздавать (на сюзе).

XFS тоже не идеальная, мягко говоря. Но, она себе ведет предсказуемо.

Года 4 назад все работало хорошо, нестабильность btrfs – городская легенда.

Другое дело, что я не верю, что оно выживет без поддержки шапки.

Ты главное бакапы делай на отдельный диск, чтобы когда добьешь бтрфс командой repair было из чего восстановиться.

Balance делать обязательно. Иначе у тебя «место закончилось» в то время когда физически оно есть.

Это на рейдах наверное?

Это вообще. Как было 12 лет назад, так и осталось. И это неустранимо в принципе, такая архитектура B*-деревьев. Что хорошо для Oracle DB, плохо для ФС.

Если что, btrfs balance не имеет никакого отношения к балансировке B*-деревьев и к самим B*-деревьям. Это сугубо «фишка» двухуровневого аллокатора дискового пространства в btrfs.

А, то есть эти баги — кого надо баги? :)

Не вижу никакой разницы между багами в XFS, вызывающими повреждение ФС при определённых условиях, и багами в btrfs, вызывающими повреждение ФС при определённых (других) условиях. Не вижу, почему одни баги «предсказуемее» других.

Не вижу, почему одни баги «предсказуемее» других

Я не говорю, что баги предсказуемее. Баги есть баги, они везде одинаковые. Однако, XFS не требует ни специальных навыков для использования (то есть, пардон, чтобы обойти все баги и ни в один не вляпаться), ни постоянного мониторинга и обслуживания. Живет себе и живет, примерно как ext4 (берем за скобки mainline ядра, т.к. XFS - сугубо красношапое поделие и никто всерьез не тестит то, как оно работает за пределами RHEL).

В общем - выходит, что в ней меньше архитектурных ошибок.

чтобы обойти все баги и ни в один не вляпаться

Нет, это значит лишь то что для получения аналогичного функционала, придется мостырить бутерброд из сторонних утилит (mdadm, cryptsetup, edquota и как принято еще и поверх на lvm), естественно, увеличивая вероятность вляпаться фатально на порядки.

ни постоянного мониторинга и обслуживания

Вы это серьезно? У вас есть идеи, почему на ssd дисках нужно держать свободными хотя бы 20%? Вообще на любой ФС.

А понимаете что нехорошее случится в любой ФС, когда системный диск переполнится полностью? А догадываетесь что будет при активном сжатии? А если еще и присутствует шифрование? А в массиве?

увеличивая на порядки вероятность вляпаться фатально.

Каким образом можно вляпаться фатально с тем, что просто работает как следует по дефолту и кушать не просит? С высоты своего почти 15-летнего опыта использования этих «бутербродов» могу сказать одно - оно просто неубиваемое.

У вас есть идеи, почему на ssd дисках нужно держать свободными хотя бы 20%? Вообще на любой ФС.

У меня есть идеи не использовать такие ФС, которые выдвигают такие требования. И да, такие требования - это исключительно архитектурная ошибка таких ФС. Failed by design.

А понимаете что нехорошее случится в любой ФС, когда системный диск переполнится полностью?

Нехорошее - случится. Но ФС не помрет, её достаточно будет почистить и убраться.

B tree не имеет отношения к B-Tree FS. Как много нам открытий чудных готовит средний эксперт с ЛОРа.

Объясняю, инженеры Oracle не осилили сделать ФС на B-деревьях. Отсюда постоянно деградация ФС, ее поломка в произвольные моменты времени и так далее.

Все эти ваши ребалансы дерева ФС - один огромный костыль над тем, что само работать не может. Лучше бы разрешили ZFS быть в ядре, но луддиты из IBM никогда этого не допустят.

Скорее всего, ты что-то недопонял

добьешь бтрфс командой repair

Я уже понял, что 'btrfs check --repair' - это такая злая шутка от разработчиков btrfs.

https://www.suse.com/support/kb/doc/?id=000018769

WARNING: Using ‘–repair’ can further damage a filesystem instead of helping if it can’t fix your particular issue.

Открою страшную тайну: средний эксперт с ЛОРа здесь ты :)

Удачи.

Все зависит от того на каком дистре это крутиться. С учетом того что СУСЕ бухтела про РЕДХАТ, есть основание что они тщательно следят за патчами от Шапки и есть аероятность что btrfs в Suse то же стабильно работает.

ребалансы дерева ФС

Оно называется balance потому что изначально должно балансировать распределение блоков между дисками МАССИВА. Но потом выяснилось, что и для одного диска оно полезно, т.к. получается дефрагментация на уроне блоков данных (не файлов). В то время как filesystem defragment оперирует как раз файлами.

Конкретно с балансировкой B-tree, кроме названия, ничего общего нет от слова совсем.

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

Какие файловые системы для linux со сжатием zstd ты знаешь?

Существует несколько файловых систем для Linux, которые поддерживают сжатие с использованием алгоритма zstd. Некоторые из них:

Btrfs - это современная файловая система, которая поддерживает сжатие с использованием алгоритма zstd. Btrfs также поддерживает другие алгоритмы сжатия, такие как gzip и lzo.

SquashFS - это файловая система только для чтения, которая используется для создания сжатых образов файловой системы. SquashFS поддерживает сжатие с использованием алгоритма zstd, начиная с версии 4.4.

ZFS - это файловая система с открытым исходным кодом, которая поддерживает сжатие данных. В ZFS можно использовать алгоритм сжатия zstd с помощью опции compression=zstd.

XFS - это быстрая файловая система, которая поддерживает сжатие данных. В XFS можно использовать алгоритм сжатия zstd с помощью опции -o compress=zstd.

F2FS - это файловая система, которая разработана специально для флэш-накопителей. F2FS поддерживает сжатие данных с использованием алгоритма zstd начиная с версии 5.3 ядра Linux.

Я слышал что btrfs работает по принципу cow и это может негативно сказаться на долговечности накопителя, это так?

Действительно, Btrfs (B-Tree File System) работает по принципу Copy-On-Write (COW), который может повлиять на долговечность накопителя. Однако, не следует считать, что это является прямым негативным фактором, так как это зависит от конкретной ситуации и условий эксплуатации.

Принцип Copy-On-Write означает, что при записи данных в файловую систему Btrfs, вместо того чтобы перезаписывать существующие данные, создается новая копия данных (snapshot), которая записывается на свободное место на диске. Это позволяет избежать потери данных при сбое системы или при выполнении других операций записи.

Однако, этот принцип работы может привести к увеличению количества операций записи на диск, что может негативно сказаться на долговечности накопителя, особенно если он используется в условиях высокой нагрузки. Кроме того, Btrfs требует больше ресурсов (памяти и процессорного времени) для работы, чем другие файловые системы, что может сказаться на производительности системы.

Однако, современные накопители обладают высокой долговечностью и способны выдерживать большое количество операций записи. Кроме того, Btrfs обеспечивает надежную проверку целостности данных и функции копирования (snapshots), которые могут повысить безопасность и защиту данных на накопителе.

Таким образом, использование Btrfs может быть полезным в некоторых случаях, например, в условиях высокой нагрузки на систему или при работе с критически важными данными. Однако, при выборе файловой системы необходимо учитывать конкретные потребности и условия эксплуатации, а также принимать меры для обеспечения безопасности и надежности хранения данных.

xfs тоже работает по принципу cow ?

XFS (Extended File System) не работает по принципу Copy-On-Write (COW), который используется в Btrfs. Вместо этого XFS использует принцип delayed allocation, который позволяет отложить выделение блоков на диске для записи данных до тех пор, пока это не станет необходимым. Это позволяет уменьшить количество операций записи на диск и улучшить производительность.

Когда данные записываются на диск в XFS, они записываются непосредственно в блоки на диске, а не создаются новые копии данных, как это происходит в Btrfs. Это может повысить производительность и уменьшить износ накопителя.

Однако, XFS также использует технику кэширования данных, которая может привести к потере данных в случае сбоя системы или отключения питания. Для уменьшения риска потери данных в XFS рекомендуется использовать журналирование (journaling), которое позволяет восстановить данные после сбоя.

Таким образом, XFS и Btrfs используют различные принципы работы с данными. XFS использует delayed allocation, который позволяет уменьшить количество операций записи на диск, а Btrfs использует принцип Copy-On-Write, который позволяет избежать потери данных при сбое системы или при выполнении других операций записи. Однако, как и в случае с Btrfs, при выборе XFS необходимо учитывать конкретные потребности и условия эксплуатации, а также принимать меры для обеспечения безопасности и надежности хранения данных.

Я вот думал на btrfs сидеть, прикольно же на самом деле, но мысль, что мой emmc может погибнуть от этого cow меня немного напрягает. Сейчас юзаю f2fs но у нее тоже недостатки есть, например нельзя уменьшить раздел, то есть в случае резкой необходимости окошки в дуалбут уже не поставить, это кринж конечно (не фанат этого слова, но в самом деле). Смотри в сторону xfs, гопатыч говорит, что это для серьезного продакшена, а значит надежно и сжатие там тоже есть.

Но потом выяснилось

Звучит как инженерный подход к построению отказоустойчивой ФС.

У меня вообще autodefrag долго был в опциях монтирования…

xfs научили уменьшать раздел ?

XFS - это быстрая файловая система, которая поддерживает сжатие данных. В XFS можно использовать алгоритм сжатия zstd с помощью опции -o compress=zstd.

Гопатыч из будущего пишет. Спроси у него, какая там стоимость золота и курс биткоина.

Лол, действительно! Однако все остальное вроде сходится. Ну тс за сжатие не спрашивал, он спрашивал скорее за надежность. В любом случае пусть рассмотрит этот вариант, может ему зайдет.

Так а что получается, если мне условно хочется сжатия в фс, то у меня даже выбора как такового нет? Только бтрфс? Я только что гопатыча за оверхед спросил, он говорит что с моей заглушкой вместо процессора (n4020) я могу смело 3-5 уровень втыкать и никакого оверхеда не почувствую. Спрошу на всякий случай и тут: если накатывать бтрфс, что там по уровням сжатия? В прошлый раз использовал zstd:1 дабы получить и сжатие получить и рыбку съесть или можно в самом деле больше указывать?

И еще сразу вопрос тогда, если отключить cow, как это повлияет на производительность?

Мнение гопатыча:

...В целом, если вы не используете Btrfs в качестве основной файловой системы для хранения критически важных данных, отключение COW может быть безопасным и полезным для повышения производительности. Однако, если важна надежность данных, то лучше оставить COW включенным....

А что ещё можно отключить в btrfs?

Не знаю, спроси у гопатыча

Так а что получается, если мне условно хочется сжатия в фс, то у меня даже выбора как такового нет? Только бтрфс?

В ZFS тоже есть сжатие, если не пугает сборка стороннего модуля ядра.

В прошлый раз использовал zstd:1 дабы получить и сжатие получить и рыбку съесть или можно в самом деле больше указывать?

Что zstd:1, что zstd:3 дают плюс минус одинаковый коэффициент сжатия, во всяком случае по моему опыту. Что касается более высоких уровней, есть вот такое сравнение, правда довольно старое.

И еще сразу вопрос тогда, если отключить cow, как это повлияет на производительность?

Повлияет положительно, но без cow сжатие работать не будет.

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

Ты почитай как в C++ завезли шаблоны.

Жену убил, видимо.