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

Когда я использовал Btrfs на gentoo, я вообще не делал эти balance и scrub. А зачем? Проблем не возникало, правда, я из всех фич использовал только сжатие и снапшоты.

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

Если диск не супер быстрый, а проц не супер медленный то сжатие скорее ускорит работу (читать/писать то меньше)

А мес та оно экономит так порядочно

root
Processed 753756 files, 641555 regular extents (700353 refs), 413751 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       68%       49G          72G          78G       
none       100%       38G          38G          39G       
zstd        31%       10G          33G          37G       
prealloc   100%      144M         144M         245M 

home
Processed 629366 files, 645359 regular extents (677332 refs), 286543 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       74%       57G          77G          78G       
none       100%       49G          49G          49G       
zstd        28%      7.9G          28G          28G       
prealloc   100%       55M          55M          89M       

Если бы оно еще не корраптилось в зависимости от погоды в Африке и фазы луны…

На каком это уровне zstd компрессии?

Пять лет btrfs. Ничего не делаю. Недавно решил дефрагментировать. В процессе этого было сожрано всё свободное место на диске и дефрагментация завершилась ошибкой. Причина была в наличии снапшотов. Пришлось их удалить. После этого дефрагментация прошла успешно. Потом первый раз в жизни сделал balance. Разницы не почувствовал.

Ничего не делаю, ФС примортирована с опциями discard,compress=zstd (по умолчанию третий уровень, если не указано другое, ЕМНИП). Пациент жив, пока не падал.

по умолчанию 3 уровень? Такой, пожалуй, и не нужен, полез менять на 1. Спасибо за инфу

Вот тут расписано

This will enable the zstd algorithm on the default level (which is 3).

У меня нет discard, но написано, что в ядре 6.2 эта опция включена по-умолчанию.

уже поменял, спасибо

Свечку в церкви поставить и ведический ритуал с брахманом провести не забудьте.

А 5сли серьёзно: уже не помню сколько лет (много больше пяти) живу на btrfs. Изредка делаю scrub, дабы убедиться что с ним всё в порядке. За это время было пару раз его ломал на внешнем жёстком диске (я ломал, а не он ломался) неосторожными действиями.

Разработчики btrfs не рекомендуют balance по расписанию. Discard бывает вредным для производительности, если что - можно заменить на периодический fstrim.

Сжатие - огонь. У меня благодаря ему рачик для одноплатника живёт на двухгиговой флешке.

я ломал, а не он ломался

А может он сам просил, чтобы ты его ломал (полностью)?

Разработчики btrfs не рекомендуют balance по расписанию.

…без фильтров. Но там стоят такие фильтры: 10% (data) and 5% (metadata).

Третий уровень. На файлопомойке седьмой (ХЗ почему так, не помню)

файлопомойка
Processed 4006082 files, 3130566 regular extents (3167644 refs), 2260834 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       92%      1.4T         1.5T         1.6T       
none       100%      1.4T         1.4T         1.5T       
zstd        28%       44G         159G         161G

У меня SUSE с зашифрованным / через LUKS. Чтобы TRIM over LUKS периодический работал, я для приличия и успокоения души для / в fstab и crypttab прописал discard

Подробнее

Когда я использовал Btrfs на gentoo

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

Больше я к этому не возвращался

ОК. Чехам из зюзи явно виднее, у них там несколько разработчиков самой ФС.

Btrfs на microsd у Дека. Ничего не делаю, только включил сжатие. Полет отличный.

у Дека

не распарсил, поясни, плиз

Steam Deck

Тут скорее комбо шифрование+сжатие с переполнением раздела.

Это уже не принципиально. Если фс корраптится от того, что её используют там, где другая фс не корраптится от того, что её используют - она сырая и к использованию не готова.

Скажите, а за ext4 нужен какой-нибудь уход (ну кроме очевидных бэкапов, разумеется)? А то оно у меня просто живёт и работает, я с ним ничего такого не делаю, может, зря. Когда-то уверяли, что ему даже дефрагментация не нужна (тут вопрос спорный).

Дефрагментация (почти) не нужна, если data=ordered в опциях монтирования. Но так как дефрагментатора все равно нет адекватного, то нужна она или нет, узнать нам не дано :)

дефрагментатора все равно нет адекватного

А как ты оценил неадекватность существующего?

Есть у ext одна проблемка

Аномальное поведение одной директории (комментарий)

Аномальное поведение одной директории (комментарий)

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

Жуть-муть.

Кстати, лет пять назад был какой-то энтузиаст, который обкритиковал все широко распространённые ФС линукса (4 штуки), и запилил свою, непохожую на другие. Чем там всё закончилось?

bcachefs?

https://www.phoronix.com/news/Bcachefs-Plans-For-Linux-6.6

Спасибо! Оно!

Да, звучит вкусно. Но интересно, как там будет с фатальными недостатками комбайнов…

лет пять пообкатывают, а там видно будет

Лучше не связываться с бякой. Всё равно скоро смерджат bcachefs c mainline и можно будет забыть btrfs как страшный сон.

был какой-то энтузиаст, который обкритиковал все широко распространённые ФС линукса (4 штуки), и запилил свою

У меня сразу ассоциация с Эдуардом Шишкиным и его reiser4/reiser5. )

p.s. В интервью он высказывался негативно о Btrfs. Это 2021 год.

Ну, я так понимаю, для десктопа, всё же, btrfs подойдёт.

Если уж ты даешь ссылку на АВТОРИТЕТА, то хотя бы сам ее читай :)

После Btrfs с большой вероятностью место такого «будущего» займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть!

Чтобы возлагать надежды на bcachefs, ее авторы, как минимум, должны найти фатальные недостатки btrfs, из-за которых она рассыпается, и (может тогда новой ФС не понадобится) заявить: вот фатальные недостатки, мы их исправили так-то и так-то.

А то очередное строительство коммунизма получается: в этот раз все точно будет по другому!

Я давно думаю о поддержке снимков (snapshots) и ещё не определился с тем, как их реализовать для простых Reiser4 томов

Офигенно, конечно, критиковать «кривые ФС», когда своя распрекрасная Reiser4 даже снимки не умеет, лол.

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

Потому что … ?

А как в Macos реализована Тайм Машина? Просто rsync’ом пофайлово копируют? Или что-то типа снапшотов там есть?

В APFS есть снапшоты.

Потому что … ?

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

Понятно, аргументов нет.

Аргументов много, даже само по себе наличие этого треда - уже аргумент, но фанбои такие фанбои.

Забавное интервью, конечно. Столько желчи в адрес Торвальдса и прочих «говнокодеров». При этом Linux работает здесь и сейчас, а Шишкин пилит свою «академически правильную» ФС уже хз сколько лет и даже сейчас:

Реализовать свои задумки мне удалось пока что процентов на 10

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

даже само по себе наличие этого треда - уже аргумент

Не аргумент, это у тебя логическая ошибка.