Самый простой способ
btrfs-zero-log /dev/sda5
Вы получаете эту проблему, потому что транзакция (запись или удаление) застряла в журнале журнала, а диск не соответствует ей.
Как это устроено:
Поэтому, когда данные записываются 1-й раз, они записываются в журнал, а затем на диск (или одновременно, но журнал просто сохраняет метаданные о предстоящей записи - не уверен ... нужно больше исследований в этой части) ...
В любом случае, если вы выключите систему в середине этой записи / удаления или сделаете что-нибудь взломавшее систему (отсоедините USB, который содержит вашу точку монтирования btrfs), тогда, когда он вернет, что монтирование не будет работать, он потерпит неудачу ( dmesg и btrfsck будут покажу вам ошибки более подробно) ...
Глядя на dmesg, вы увидите те же самые сообщения.
Вы увидите что-то вроде этого:
parent transid verify failed on 109973766144 wanted 1823 found 1821
Это означает, что btrfs хотел передать 1826 (Это было в журнале), но на диске он увидел 1821. Таким образом, диск находился на расстоянии 2 транзакций от синхронизации с журналом. Лично я рискну вести журнал brtfs-zero-log только потому, что его всего 2 транзакции. Но чтобы быть на 100% безопасным, если это ваши единственные данные (кстати, если у вас есть важные данные, вы НИКОГДА не должны иметь только 1 их копию, всегда иметь копию / резервную копию в безопасном другом месте - обвинять создателей btrfs оправдать себя за отсутствие ответственности за отсутствие резервной копии - btrfs - это не решение для резервного копирования, а файловая система - ничто не является истинным решением для резервного копирования, кроме наличия его копии в другом месте, где нет даже четных или зеркальных дисков, а истинное резервное копирование где-то под землей в Альпах, а его активная копия в вашем офисе в Техасе)
parent transid verify failed on 31302336512 wanted 62455 found 62456
Здесь журналу нужно 62455, но на 62456 впереди диск, так что в вашем случае я бы просто очистил журнал. На этот раз журнал не обновлялся. Опять же, я сказал вам, что это безопасная вещь, если это ваши единственные данные и их мегакритические (позор вам), и я бы сначала выполнил следующие операции, чтобы быть в безопасности.
Запуск btrfsck / dev / sda5 (который, кстати, просто делает проверку только для чтения, поэтому он полностью безопасен, это единственные опции btrfsck, о которых вам нужно беспокоиться) также покажет вам эти сообщения.
Но будьте осторожны, если эти данные имеют решающее значение, я бы сначала сделал (как сказали другие мужчины)
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
Затем cp или rsync все ваши файлы в безопасное место, затем, когда безопасно, btrfs-zero-log, если это была успешная операция, вы потратили много времени на резервное копирование вашей системы (но если это не удалось, вы просто сохранили жопа)
Затем, если монтирование не удалось, выполните восстановление btrfs (дамп системы, насколько я понимаю, это возобновляемая операция, однако он время от времени продолжает запрашивать Y или y, поэтому следите за выходными данными)
btrfs restore /dev/sda5 /USB
Затем, когда безопасно (когда восстановление btrfs выполнено), выполните btrfs-zero-log, если это была успешная операция, вы потратили много времени на резервное копирование вашей системы (но если она не удалась, вы просто сохранили свою задницу)
Вы можете запустить экран первым
screen /bin/bash
btrfs restore /dev/sda5 /USB
Примечание на экране
Чтобы отсоединиться (команда все еще будет выполняться): CONTROL-a, затем введите «: detach» без кавычек, затем нажмите ENTER
Другой способ отсоединения: затем закройте замазку или ваш терминал, и он отсоединится (команда / восстановление все равно будет работать).
Чтобы проверить это, просто вернитесь к нему:
screen -x
screen -x будет подключаться к сеансам, даже если он отключен, и в отличие от -h говорит, что он подключится, даже если он уже подключен)
Если у вас есть несколько экранов, screen -x скажет, что вам нужно быть более конкретным для присоединения к сеансу:
screen -ls
Для списка всех сессий, это легко запомнить.
чтобы увидеть PID, вы также можете сделать это:
ps aux | grep screen
Как только вы узнаете свой PID, запустите экран следующим образом:
screen -x PID
Это будет прикреплено к конкретной сессии. Вы можете иметь несколько сессий / замазок, прикрепленных к одному и тому же экрану (они будут выводить один и тот же текст, вы можете набирать команды в одной и они будут отражаться в другой замазке)
nospace_cache?Ответ Питера решил проблему для меня, но не на Ubuntu. У меня был
/homeраздел btrfs'd, который, конечно, был поврежден. Система не будет загружаться, потому что она была включенаfstab. Я вошел в режим обслуживания, хэшировал строку с этим разделом и нормально загрузился (у меня был запасной раздел ext4, который я мог использовать как/home).Я смонтировал раздел вручную с помощью следующей команды:
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3и на самом деле был в состоянии сохранить мои данные. Хотя это не займет много времени, чтобы установить его. Так что СПАСИБО Петру.источник
ro = только для чтения
Это работа для меня
источник
У меня такая же проблема. После перезагрузки я больше не мог смонтировать раздел btrfs. Однако ни одно из упомянутых здесь решений не может решить эту проблему.
Для меня это исправило обновление ядра с 3.10 до 3.12. После перезагрузки раздел btrfs можно снова смонтировать.
источник