Как сейчас обстоят дела с Btrfs?

Норм.

Она по-прежнему может потерять данные, или уже можно нормально пользоваться?

Любая файловая система может потерять данные.

В общем, поделитесь мнением, пожалуйста

УМВР ЧЯДНТ?

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

В рамках одного блочного устройства хорошо. Лучше включать free space tree через опцию монтирования space_cache=v2 (достаточно один раз смонтировать, но remount не прокатит) чтобы кеш свободного места был тоже защищён CoW.

raid56 всё ещё только для тестирования т.к. write hole не решён. В режиме мультидевайсов всё ещё не замечает как устройтва исчезают из под неё.

P.S. косякнул с ответом, намеревался ответить ТСу.

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

Лучше включать free space tree через опцию монтирования space_cache=v2

The btrfs(8) command currently only has read-only support for v2. A read-write command may be run on a v2 filesystem by clearing the cache, running the command, and then remounting with space_cache=v2.

Отлично, че. Т.е. про снэпшоты можно забыть с этой опцией?

был тоже защищён CoW

WUT?

УМННР ЧЯДНТ?

Опыт работы с ней по-прежнему печальный. Одна история про ВНЕЗАПНО восстановленый временный файл из-за которого гнум дальше логина не ходил чего стоит. А со старой доброй ext4 такого у меня еще не было...

Хотя вот на файлопомойке она себя прекрасно показала как альтернатива ZFS, сжимает хорошо, сама себе рейд...

Статус Btrfs

Холостая, RH не взял в жёны. Можешь подкатывать.

У меня на десктопе работает год. Из функционала активно используются только субвольюмы и снапшоты (по 24 штуки в сутки, но живут не долго, только пока бекапилка не отработает). Брат жив. Но это не показатель.

ХЗ чей это глюк, сабжа или Mate: при очистке корзины корзина на одном из субвольюмов не чистится. Периодически нужно вручную грохать содержимое /mountpoint/.Trash-1000

УМВР, пользуюсь на сервере.

Отлично, че. Т.е. про снэпшоты можно забыть с этой опцией?

Возможно, данные устарели.

# mount | grep /mnt/data
/dev/mapper/storage1 on /mnt/data type btrfs (rw,relatime,space_cache=v2,autodefrag,subvolid=5,subvol=/)

# btrfs sub snap /mnt/data /mnt/data/.snapshot
Create a snapshot of '/mnt/data' in '/mnt/data/.snapshot'

# btrfs sub del /mnt/data/.snapshot
Delete subvolume (no-commit): '/mnt/data/.snapshot'

# btrfs fi resize 1:-1G /mnt/data
Resize '/mnt/data' of '1:-1G'

На самом деле я не очень понимаю, какой там нужен «support for v2», т. к. btrfs(8) ничего не делает сама, а только командует драйвером в ядре. Единственное исключение — btrfs check, но если ты делаешь btrfs check --repair, то space cache — это последнее, что тебя волнует (и его можно грохнуть прямо там же, хоть v1, хоть v2).

Проблем за 3 или 4 года не было, но я вернулся на ext4

суся давно уже взяла

Холостая, RH не взял в жёны. Можешь подкатывать.

Там SuSe давно. И лицокнига. И ещё парочка известных:
https://btrfs.wiki.kernel.org/index.php/Contributors

Год на HDD, пол года на SSD. Работает хорошо, сбоев нет. Raid56 не тестил, но 2 HDD в raid0 живут хорошо

Отлично, че. Т.е. про снэпшоты можно забыть с этой опцией?

Нет, снапшоты ни при чём.

WUT?

Сейчас в btrfs по умолчанию free space cache v1, который часто перезаписывается на месте без CoW (Copy-on-Write). Из-за этого в случае пропадания питания он может оказаться в неконсистетном состоянии. Драйвер фс проверяет generation кеша при его использовании и обычно ловит такой некорректный кеш и инвалидирует его. Однако есть малый шанс, что повреждённый кеш может пройти все проверки и быть использован драйвером для аллокации новых экстентов. На основании некорректного кеша драйвер примет неверное решение об аллокации и возможно перезапишет какие-либо экстенты других файлов новыми, что вызовет повреждение данных.

Free space tree защищен CoW как и все метаданные в btrfs и не подвержен этому.

Free space tree ещё не включен по умолчанию потому что btrfs check --repair не умеет его обновлять и поэтому требуется вызывать «btrfs check --clear-space-cache v2» перед «btrfs check --repair». Стоит напомнить, что btrfs check --repair - всё ещё опасная операция и лучше посоветоваться в списке рассылки linux-btrfs перед её вызовом.
[1 (spinics.net)] [2 (spinics.net)]

Также есть специальная страница вики со статусом.

Да суся давно уже всем даёт...

https://www.omgubuntu.co.uk/2018/07/suse-linux-sold-in-2-5-billion-deal

Надо было на XFS.

Нет её поддержки известных приложений восстановлений данных.

«btrfs restore» или нужно именно восстановление недавно удаленных файлов?

Почему.

Разницы особой нет.

Надобность в снапшотах отпала, и я подумал, что ext4 будет быстрее. Оказалось, что никакой разницы.

У меня похожая причина, но я даже не начал ими пользоваться (надобности не возникло). Использовать же такую крутую ФС только ради контроля целостности данных мне показалось бессмысленным.

Кстати, малость соврал. На Бтрфс из-за сжатия файлов обновления системы проходили быстрее.

Лол, я же тоже им пользовался для /opt/games. Раза в два уменьшало объём игорей.

Ага, то есть дело именно в btrfs check —repair. Ну тогда как я и сказал :)

Сильное повреждение, когда btrfs restore и btrfsck не помогло.

Сильное повреждение, когда btrfs restore и btrfsck не помогло.

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

В ФС такого типа (btrfs, reiser4, zfs) эвристическое восстановление данных вообще не работает. У тебя содержимое файлов по определению фрагментировано (вопрос лишь в том, насколько сильно), может занимать нецелые экстенты, части могут быть вообще встроены в узлы дерева хранения, и это всё ещё и может быть сжато.

Либо ты восстанавливаешь метаданные (дерево хранения) и уже по нему пытаешься восстановить то, что осталось, либо вообще ничего не делаешь.

Ты перед тем как умничать поклацай btrfs и reiserfs одинаковым образом и попытайся их восстановить.

А давай я посоветую тебе перед тем, как умничать, научиться читать, потому что я говорю про reiser4, не reiserfs. reiserfs не занимается ни сжатием, ни CoW, а tail packing делает гораздо реже.

Synology по умолчанию предлагает с недавнего времени.

Сжатие и CPU

Подскажите пожалуйста, а если у меня слабый процессор (пенёк с 2 ядрами), то сжатие btrfs его раком поставит и лучше не использовать?

Актуальный вопрос.

Бери lz4 — им даже твоя микроволновка скорее всего сможет сжимать на скорости ввода-вывода.

Нет. (не «неактуальный», а «не поставит»)

сабж умеет lz4? на вики там

Are there other compression methods supported?

Currently no

Упс. И вправду не умеет. Я думал, что вместе с zstd там и lz4 запилили. Ну не страшно, на «пеньке с 2 ядрами» (надо полагать, SSD там и не пахнет) lzo тоже будет существенно быстрее, чем ввод-вывод.

А если SSD есть? Только небольшой, поэтому выигрыш от сжатия хочется.

Какой конкретно пенёк-то?

используй lzo при монтировании, а холодные файлы компресируй другим алгоритмом. btrfs поддерживает такую, я бы сказал, неочевидную и наркоманскую вещь, как смена сжатия на лету через рандомные команды не входящие в cli. всё есть в документации.
сам использую lzo не зависимо от процессора, для «ненужного» есть архивы — это лучше чем тормозить перманентно.

Бинарники и графончик, лол?

2020m

Лол, да. Не все жмутся, но в целом -40-50% запросто с zlib.

Ощутимо быстрее?

Нормально, lzo и zstd вряд ли заметишь. Но лучше сначала попробовать на тестовых каталогах.

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

А нужно ли? На Reiser4 в 2013 году пробовалось — эффект отрицательный (lz4 vs lzo).

В ходе дальнейших исследований (fullbench из состава LZ4 и lz4c vs lzop), было выяснено, что LZ4 теряет все свои свойства при блоках маленького размера, а проявляет заявленные свойства [5] только на больших блоках, к примеру в fullbench по умолчанию 4MiB, в lz4c 8MiB.

https://btrfs.wiki.kernel.org/index.php/Compression

Are there other compression methods supported?

Currently no, and with ZSTD, there are no further plans to add more. The LZ4 algorithm was considered but has not brought significant gains.

https://btrfs.wiki.kernel.org/index.php/FAQ#Will_btrfs_support_LZ4.3F