Вопрос или проблема
после обновления с Ubuntu 22.02.1 (ядро 5.15) до Ubuntu 24.04 с ядром 6.8 (а также 6.11), я больше не могу подключить свои BTRFS диски.
dmesg выдает мне:
[Sun Feb 23 15:08:11 2025] BTRFS info (device dm-5): first mount of filesystem d560d735-e812-49a7-bcc2-d883cbeae2f4
[Sun Feb 23 15:08:11 2025] BTRFS info (device dm-5): using crc32c (crc32c-intel) checksum algorithm
[Sun Feb 23 15:08:11 2025] BTRFS info (device dm-5): disk space caching is enabled
[Sun Feb 23 15:08:12 2025] BTRFS critical (device dm-5): corrupt leaf: block=20387303407616 slot=33 extent bytenr=9103199440896 len=8238972779538548086 invalid extent data backref objectid value 13163
[Sun Feb 23 15:08:12 2025] BTRFS error (device dm-5): read time tree block corruption detected on logical 20387303407616 mirror 1
[Sun Feb 23 15:08:12 2025] BTRFS critical (device dm-5): corrupt leaf: block=20387303407616 slot=33 extent bytenr=9103199440896 len=8238972779538548086 invalid extent data backref objectid value 13163
[Sun Feb 23 15:08:12 2025] BTRFS error (device dm-5): read time tree block corruption detected on logical 20387303407616 mirror 2
[Sun Feb 23 15:08:12 2025] BTRFS error (device dm-5): failed to read block groups: -5
[Sun Feb 23 15:08:12 2025] BTRFS error (device dm-5): open_ctree failed
Были выполнены следующие проверки:
1. btrfsck –readonly /dev/mapper/data1_crypt
Открытие файловой системы для проверки...
Проверка файловой системы на /dev/mapper/data1_crypt
UUID: d560d735-e812-49a7-bcc2-d883cbeae2f4
[1/7] проверка корневых элементов
[2/7] проверка экстентов
[3/7] проверка кэша свободного места
[4/7] проверка корней файловой системы
[5/7] проверка только csums элементов (без проверки данных)
[6/7] проверка корневых ссылок
[7/7] проверка квотных групп пропущена (не включена на этой FS)
обнаружено 5883597525113 байт использовано, ошибок не найдено
всего csums байт: 5729361204
всего байт дерева: 15929737216
всего байт дерева fs: 9227829248
всего байт дерева экстентов: 635011072
отходы места btree байт: 1907771393
блоки данных файлов выделены: 57498707316736
ссылается 46500400185344
2. btrfs-find-root /dev/mapper/data1_crypt
Суперблок считает, что поколение 294543
Суперблок считает, что уровень 1
Найдено корневое дерево на 19305371582464 gen 294543 level 1
Блок 19305203253248 (gen: 294542 level: 1) кажется хорошим, но поколение/уровень не совпадает, требуется gen: 294543 level: 1
Блок 19305194897408 (gen: 294541 level: 1) кажется хорошим, но поколение/уровень не совпадает, требуется gen: 294543 level: 1
Блок 19305183739904 (gen: 294540 level: 0) кажется хорошим, но поколение/уровень не совпадает, требуется gen: 294543 level: 1
Блок 19305371500544 (gen: 294538 level: 0) кажется хорошим, но поколение/уровень не совпадает, требуется gen: 294543 level: 1
Блок 19305367502848 (gen: 294538 level: 0) кажется хорошим, но поколение/уровень не совпадает, требуется gen: 294543 level: 1
3. btrfs rescue super-recover -v /dev/mapper/data1_crypt
Все устройства:
Устройство: id = 2, name = /dev/mapper/data2_crypt
Устройство: id = 1, name = /dev/mapper/data1_crypt
До восстановления:
[Все хорошие суперблоки]:
имя устройства = /dev/mapper/data2_crypt
суперблок bytenr = 65536
имя устройства = /dev/mapper/data2_crypt
суперблок bytenr = 67108864
имя устройства = /dev/mapper/data2_crypt
суперблок bytenr = 274877906944
имя устройства = /dev/mapper/data1_crypt
суперблок bytenr = 65536
имя устройства = /dev/mapper/data1_crypt
суперблок bytenr = 67108864
имя устройства = /dev/mapper/data1_crypt
суперблок bytenr = 274877906944
[Все плохие суперблоки]:
Все суперблоки действительны, восстановление не требуется
4. smartctl -a
--> Нет ошибок, нет проблем
5. btrfs scrub выполняется ежемесячно:
sudo btrfs device stats /dev/mapper/data1_crypt
[/dev/mapper/data1_crypt].write_io_errs 0
[/dev/mapper/data1_crypt].read_io_errs 0
[/dev/mapper/data1_crypt].flush_io_errs 0
[/dev/mapper/data1_crypt].corruption_errs 0
[/dev/mapper/data1_crypt].generation_errs 0
Что я пробовал до сих пор (с чистой загрузкой с Ubuntu 22.04 Live-ISO):
6. Несколько попыток монтирования (без успеха на kernel 6.8/6.11):
mount -o recovery /dev/mapper/data1_crypt /media/ddd
mount -vs -t btrfs -o ro,recovery,errors=continue /dev/mapper/data1_crypt /media/ddd
mount -t btrfs -o degraded,noatime,nodiratime,clear_cache /dev/mapper/data1-crypt /mnt/Daten
7. btrfs rescue zero-log /dev/mapper/data1-crypt
8. btrfs rescue clear-ino-cache /dev/mapper/data1-crypt
Не удается найти группу блоков для 0
ОШИБКА: не удалось очистить кэш inos: недостаточно места на устройстве
9. btrfs rescue clear-space-cache v1 /dev/mapper/data1-crypt
Не удается найти группу блоков для 0
ОШИБКА: не удалось очистить кэш свободного места
утечка буфера экстентов: начало 20449393967104 длина 16384
10. btrfs inspect-internal tree-stats /dev/mapper/data1-crypt
предупреждение, устройство 2 отсутствует
Вычисление размера корневого дерева
Общий размер: 2.28MiB
Встроенные данные: 0.00B
Общее количество обращений: 140
Прямых обращений: 70
Обратных обращений: 70
Средняя длина обращения: 2.09TiB
Гистограмма обращений
16384 - 185712640: 21 ###
290275328 - 50034622464: 21 ###
61473767424 - 490582196224: 21 ###
490944790528 - 932145905664: 21 ###
992462012416 - 1556186071040: 21 ###
1556985511936 - 10512543825920: 21 ###
10512621191168 - 12069176721408: 8 #
Общее количество кластеров: 4
Средний размер кластера: 36.00KiB
Минимальный размер кластера: 32.00KiB
Максимальный размер кластера: 48.00KiB
Общий диапазон диска: 11.00TiB
Общее время чтения: 0 s 29 μs
Уровни: 2
Общее количество узлов: 146
На уровне 0: 145
На уровне 1: 1 (средняя загрузка 145)
Вычисление размера дерева экстентов
Ошибка сегментации
dmesg
[Tue Mar 4 08:50:46 2025] btrfs[7804]: ошибка сегментации в 0 ip 0000564b44894e65 sp 00007ffe6b099710 ошибка 4 в btrfs[564b4482b000+71000]
[Tue Mar 4 08:50:46 2025] Код: 8d 74 24 30 48 8d ac 24 98 00 00 00 49 89 c4 4c 89 f7 e8 43 a5 f9 ff 31 c0 b9 30 00 00 00 48 89 ef f3 ab 31 f6 48 8d 7c 24 10 <49> 8b 04 24 48 c7 84 24 e8 00 00 00 ff ff ff ff 0f b6 98 dc 00 00
Теперь я не знаю, что ещё можно сделать, и надеюсь, кто-то сможет мне помочь.
И, тем не менее, мне кажется странным, что я могу монтировать диск с ядром 5.15 и никаких ошибок не возникает…
Спасибо и с уважением,
Маркус
Ответ или решение
Проблема, с которой столкнулся Маркус, связана с невозможностью монтирования файловой системы Btrfs после обновления ядра с версии 5.15 на 6.8 и 6.11 Ubuntu. Применяя структуру TEA (теория, пример, применение), рассмотрим данную ситуацию подробно.
Теория
Btrfs, или B-Tree File System, является прогрессивной файловой системой, ориентированной на высокую надёжность и масштабируемость. Она поддерживает такие функции, как снепшоты, контрольные суммы данных и файлов, динамическое распределение дискового пространства и многие другие. Однако, несмотря на её преимущества, Btrfs иногда демонстрирует сложности с совместимостью между версиями различных ядер Linux.
Одним из наиболее распространенных видов ошибок при работе с Btrfs являются проблемы с "corrupt leaf" (повреждённый лист), как указано в логах dmesg. Листья в Btrfs — это конечные узлы структуры дерева, которые содержат данные файлов и метаданные. Если лист поврежден, это может привести к несогласованности данных или невозможности доступа к ним.
Обновление ядра часто меняет внутреннее устройство драйверов файловой системы, поэтому возможно, что новый драйвер обнаруживает повреждения, не распознанные или игнорируемые ранее. Вдобавок, различия в версиях Btrfs могут оказывать влияние на механизм кэширования и проверки дискового пространства, что также вызывает ошибки монтирования.
Пример
Рассмотрим логи dmesg, предоставленные Маркусом:
BTRFS critical (device dm-5): corrupt leaf: block=20387303407616 slot=33 ...
BTRFS error (device dm-5): read time tree block corruption detected...
BTRFS error (device dm-5): failed to read block groups: -5
BTRFS error (device dm-5): open_ctree failedЗдесь указано, что ошибка возникает из-за "corrupt leaf", что вызывает невозможность чтения блоков и приводит к сбою при операции open_ctree.
При использовании btrfs check в режиме --readonly результаты не показывают никаких явных ошибок, что может указывать на известную проблему контролируемого восстановления, которую фиксируют более старые версии драйверов.
Применение
Для решения проблемы Майкросу необходимо руководство по нескольким направлениям:
1. Проверка совместимости между драйверами Btrfs и ядром: Один из первых шагов — убеждение в том, что используемое ядро поддерживает необходимую версию Btrfs. Проверять, обновилось ли программное обеспечение ядра Btrfs до той версии, которая может иметь улучшенные алгоритмы работы с данными.
2. Использование инструмента btrfs rescue: Несмотря на то, что Майкрос уже использовал btrfs rescue zero-log, можно попробовать другие команды этой утилиты, например, btrfs rescue chunk-recover, для попытки восстановления логических структур файловой системы.
3. Попытка монтирования с использованием параметров восстановления:
Маркус может попробовать монтировать с рядом опций восстановления. Например:
mount -o ro,nodatacow,recovery,degraded /dev/mapper/data1_crypt /media/dddЭти параметры помогут игнорировать ошибки записи и попытаться восстановиться из данных, которые не подвергались изменениям.
4. Диагностика и действия, относящиеся к повреждённым данным:
Если рабочие данные не слишком критичны или у Маркуса есть резервные копии, можно попытаться играющим методом исправить это, используя btrfs check --repair, важно, что это может привести к потере данных.
5. Контактирование с сообществом или профессиональной поддержка:
Если никакие ущождения не решат проблему, Маркус может обратиться за помощью к сообществу Ubuntu или специализированной поддержке Btrfs для более детального анализа проблемы.
Более общего совета может служить регулярное резервное копирование критичных данных на внешние устройства в предпочтительном формате. Также систематическая проверка файловой системы на предмет ошибок может свести к минимуму подобные риски при будущих обновлениях системы.