Вопросы Теги

Btrfs super-recovery говорит, что все суперблоки хороши, но монтирование не соглашается

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

#!/bin/bash
FTP_DIR=/var/lib/ftp # change to location of dir
FILESTOKEEP=7

ls -1t $FTP_DIR/*.tar | awk -v FILESTOKEEP=$FILESTOKEEP '{if (NR>FILESTOKEEP) print $0}' | xargs rm

Обычно я перечисляю все файлы в одном столбце -1 сортирую по времени модификации, сначала самые новые -t

Затем, используя awk , я устанавливаю переменную с количество файлов, заданных параметром $ FILESTOKEEP , и большее количество записей для печати.

Передача результатов в xargs , в котором будет запускаться rm в каждой строке вывода awk

Это будет работать, если сценарий не вызывается в папке который содержит файл, поскольку использование подстановочного знака в ls заставит напечатать расширенный путь.

7
06.06.2017, 17:24
2 ответа

Простая перезагрузка

Похоже, у Btrfs есть проблемы с изменением имен файлов блочных устройств (, например, /dev/sda ). У меня была такая же проблема:

Создал файловую систему Btrfs, записал некоторые данные, размонтировал, удалил диск из моей системы (это 2,5-дюймовый диск SATA ). Неделю спустя я снова подключил диск с горячей заменой, и мне не удалось его смонтировать. Can't read superblock.btrfs rescue super-recoverсказал, что все хорошо. Я даже сделал btrfs check, и это также подтвердило, что все хорошо.

У меня более старое ядро ​​:4.15-Я думаю, что это уже решено в более новой версии Btrfs (более новые ядра ), но для старых -просто перезагрузитесь.

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

Если это не работает, -попробуйте обновить ядро.

1
27.01.2020, 20:20

У меня есть Btrfs в качестве rootfs, и у меня возникла аналогичная проблема в Ubuntu 18.04 после зависания системы. Btrfs не удалось смонтировать при следующей загрузке. Я использую Ubuntu LiveUSB для загрузки и btrfs rescue zero-logустранил проблему для меня.

Деталь:

$ sudo mount -o ro /dev/nvme0n1p2 /2
mount: /2: can't read superblock on /dev/nvme0n1p2.

(Сначала я делаю резервную копию раздела с помощью dd на внешнее запоминающее устройство.)

btrfs check --check-data-csumозначает, что все в порядке. btrfs inspect-internal dump-superговорит, что суперблок в порядке, а btrfs rescue super-recoverуказывает, что ремонтировать нечего.

Но я заметил следующее сообщение ядра после попытки монтирования 

BTRFS info (device nvme0n1p2): start tree-log replay
BTRFS critical (device nvme0n1p2): corrupt leaf: root=18446744073709551610 block=1252150951936 slot=129 ino=7029 file_offset=164888576, file extent end range (169345024) goes beyond start offset (168624128) of the next file extent
BTRFS error (device nvme0n1p2): block=1252150951936 read time tree block corruption detected
BTRFS: error (device nvme0n1p2) in btrfs_replay_log:2281: errno=-5 IO failure (Failed to recover log tree)
BTRFS info (device nvme0n1p2): delayed_refs has NO entry
BTRFS error (device nvme0n1p2): open_ctree failed

Похоже, журнал дерева поврежден. Я нахожу btrfs rescue --helpговорит 

btrfs rescue zero-log <device>
    Clear the tree log. Usable if it's corrupted and prevents mount.

и btrfs rescue zero-logустранили проблему. 

$ sudo btrfs rescue zero-log /dev/nvme0n1p2
Clearing log on /dev/nvme0n1p2, previous log_root 1252152229888, level 0
2
20.09.2020, 00:37

Теги

Похожие вопросы