хм. да вроде по умолчанию так и есть...

sudo btrfs filesystem usage /
Overall:
Device size: 458.32GiB
Device allocated: 180.06GiB
Device unallocated: 278.25GiB
Device missing: 0.00B
Used: 136.10GiB
Free (estimated): 159.14GiB (min: 159.14GiB)
Data ratio: 2.00
Metadata ratio: 2.00
Global reserve: 184.31MiB (used: 0.00B)

Data,RAID1: Size:87.00GiB, Used:66.99GiB
/dev/sdc5 87.00GiB
/dev/sdd2 87.00GiB

Metadata,RAID1: Size:3.00GiB, Used:1.06GiB
/dev/sdc5 3.00GiB
/dev/sdd2 3.00GiB

System,RAID1: Size:32.00MiB, Used:16.00KiB
/dev/sdc5 32.00MiB
/dev/sdd2 32.00MiB

Хороший пример как неправильно восстанавливать btrfs.

Одним из минусов btrfs является опасность бездумного применения штатных средств для восстановления (по методу «скопировал команду из поиска»). В рассылке btrfs часто высплывали случаи, когда btrfs check --repair или другие средства делали ситуацию хуже.

SMART пишет GOOD, но Victoria показывает 198-Offline_Uncorrectable красным.

Повод задуматься.

btrfs check /dev/sda4 завершалась аварийно

Вообще первым должно быть чтение dmesg для понимания причины проблемы. Например, btrfs частно валится вместе с битой памятью. В таком случае check repair - ни о чём.

btrfs rescue zero-log /dev/sda4 выполнился, но раздел не смонтировался

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

Помогло следующее: из ветки testing установил btrfs.progs версии 5

Помогло потому что туда добавили несколько фич и вообще улучшили код. В рассылке частеньно просят обновить btrfs-progs до >5.

btrfs check --repair /dev/sda4 стал ремонтировать. Ждать не стал, прервал ремонт. Раздел смонтировался в ro и удалось все переписать.

Повезло.

Мои ошибки: Оказалось, что metadata и system были single. В

То что ты восстановил данные, ты - lucky bastard (c). Это ssd?

UPS батарея тест проходила, но не держала.

Дай угадаю: BTRFS: parent trasid verify error: wanted xxx32 found xxx30. Такого типа ошибка?

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

Эта fs теперь дефолтная в шапке?

В общем спасибо за наводку.

Ты с SUSE попутал.

Эта fs теперь дефолтная в шапке?

Шапка её депрекейтнула и выкинула из RHEL и наверное Fedora/CentOS.

И правильно сделала. Количество «ой, всё сломалось», если судить по LOR’у и Reddit’у превышает все разумные пределы.

Хорошего примера восстановления, уважаемый, никто, кроме быть может разработчиков, не знает. Заметьте, на мой конкретный вопрос в PS. никто точно не ответил, только общие фразы. Здесь много теоретиков, но мало кто реально восстанавливал btrfs.

Остальным. Критику принял.
На самом деле у меня две актуальных копии данных. Очень хотелось именно восстановить btrfs, получится или нет, проверить устойчивость к сбоям. Мне понравилось. Спасибо.

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

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

Информация есть в btrfs wiki. Нужно смотреть логи и постараться понять, что происходит (а не копировать команду из поиска). Если сходу привести в алгоритм, то получается как-то так)

1. Если проблема при монтировании (нельзя монтировать) после обновления ядра, откатываемся назад.

2. Если не из-за обновления ядра, поступаем наоборот - ставим последнюю версию ядра и btrfs-progs (второе важнее первого).

3. Если был hard reset (power fail), то используем -oro,usebackuproot.

4. Если в логах ссылка на нерабочий журнал, есть btrfs restore zero-log и -onologreplay.

5. Если checksum mismatch, то сверяем фактический и тот, который должен быть на bit flip. Если так, то проверяем ram.

6. Если раздел монтируется, юзаем scrub.

7. Если parent transid verify error: wanted на несколько генераций выше, то см. пункт 3. Если вообще далёкое число, то см. пункт 5.

8. Получаем консультацию в irc и в linux-btrfs)

9. Если идей нет, юзаем btrfs restore (лучше последняя версия).

Заметьте, на мой конкретный вопрос в PS. никто точно не ответил, только общие фразы.

PS. Есть ли возможность подключить второй диск к разделу btrfs и настроить так, чтобы metadata и system были raid1, data=single и при этом все данные писались бы исключительно на первый диск, не залезая на второй,

т.е. второй диск только для raid1 для metadata и system, а все данные только на первом диске?

Наверное нет, и вот почему. Такая конфигурация защищает metadata/systemdata от физической порчи основного диска (в котором хранится data). Она не спасает от hard reset, bad ram - если будут внесены неверные данные в основную metadata, то и в её бэкап на другом диске тоже. В случае физической порчи диска накроются данные - ну и кому такая конфигурация нужна?

Однако, я допускаю возможность реализации такого сценария. Если реально нужно, стоит обращаться в чат/рассылку, тут едва дадут 100% ответ.

Здесь много теоретиков, но мало кто реально восстанавливал btrfs.

Лол, два раза восстанавливал за 3 года. Был parent trasid verify failed, где wanted=1-2 генерации от found. Лечилось -oro,usebackuproot.

Для критиков btrfs - проблема не в btrfs, а в том, что я юзаю ноутбук со сдохшей батареей и с проводом, который можно случайно выдернуть. Такое происходит раз в 2-3 месяца, так что надежность фс неплохая (два поправимых сбоя на пару десятков вырубаний).

P.S.

Заметьте, на мой конкретный вопрос в PS. никто точно не ответил, только общие фразы.

Ага. Все специалисты с 9 утра до вечера сидят на ЛОРе, никто не работает.

Спасибо за ответ.

Наверное нет, и вот почему. Такая конфигурация защищает metadata/systemdata от физической порчи основного диска (в котором хранится data). Она не спасает от hard reset, bad ram - если будут внесены неверные данные в основную metadata, то и в её бэкап на другом диске тоже. В случае физической порчи диска накроются данные - ну и кому такая конфигурация нужна?

Поясню свою мысль: хотелось повысить скорость и вероятность восстановления целостности btrfs при сбое питания. Подумал о варианте добавить в btrfs один SSD на 32Gb для создания raid1 для Metadata и Systemdata, а Data весь оставить на HDD.
Или для восстановления btrfs нет разницы между raid1 и простым Dub, при отсутсвии сбойных секторов на HDD ?

Или для восстановления btrfs нет разницы между raid1 и простым Dub, при отсутсвии сбойных секторов на HDD ?

Думаю в большинстве случаев нет. В btrfs существует (должен существовать, если это не dedup SSD или не было при форматировании -m single) бэкап этих данных. При сбое питания запасных данных, как правило, достаточно для восстановления метаданных. Поэтому сценарий с хранением копии на другом носителе едва ли нужен (может актуален для случая, когда ssd сам дедуплицирует метаданные, но в обсуждении вроде упоминался основной диск hdd).

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

С восстановлением теперь всё понятно, спасибо.

А как поведёт себя btrfs при появлении на HDD сбойного сектора там куда попали metadata и Data? Metadata=DUP, Data=Single. Например я копирую на btrfs файл. Файл записан, metadata попали на нормальную часть диска и на сбойные сектора, а Data тоже на сбойный сектор. При чтении с metadata думаю проблем нет, btrfs выберет корректную копию. А Data для этого файла частично будут утеряны? Т.е. файл будет потерян? Btrfs как-то проверяет корректность записи на HDD или проверку корректности записи поручает контроллеру HDD ?
И я узнаю, что лишился файла сразу, при записи. Или узнаю через какое-то время при попытке этот файл считать с btrfs ?

Допустим несколько секторов с data и metadata повредились (btrfs не стала бы писать в заведомо плохие сектора - они помечаются как bad и не используются). Тогда копию метаданных можно восстановить, а вот повреждённые данные 100% нет. В лучшем случае вместо утраченного куска данных будет garbage через btrfs restore. О повреждении копии метаданных станет известно скорее всего при монтировании, данных - при чтении.

Для критиков btrfs - проблема не в btrfs, а в том, что я юзаю ноутбук со сдохшей батареей и с проводом, который можно случайно выдернуть. Такое происходит раз в 2-3 месяца, так что надежность фс неплохая (два поправимых сбоя на пару десятков вырубаний).

Надо заметить, что ext4 чаще автоматом нормально чекается. Вообще не помню, случаев, чтобы были проблемы за последние лет 7-8, кроме случая, когда к fsck oomkiller приходил.

Спасибо, видимо да

BTRFS strikes again

Ну может и это кому пригодится

https://bugs.archlinux.org/task/63733

BTRFS dev Filipe Manana (SUSE):
«So we definitely have a serious regression Until the fix gets merged to 5.2 kernels (and 5.3), I don’t really recommend running 5.2 or 5.3.»

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

Тем не менее маинтейнеры решили выпустить 5.2.14.arch2-1

Поясню, почему не считаю эту ситуацию критичной.

Этот разработчик (Filipe Manana) далеко не самый активный. Обсуждение по поводу повреждения btrfs (в котором он объявил о критической регрессии) шло в вялотекущем режиме примерно с конца июня. В этом треде отметилось несколько человек, у которых после обновления на 5.2 перестала монтироваться фс. Такие треды возникают периодически, ни к чему критическому это не приводит. В этом треде отметились более видные разработчики, и ничего страшного не произошло.