Как восстановить раздел BTRFS, который не будет монтироваться?

mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

ro = только для чтения

Эта работа для меня

У меня была такая же проблема. После перезагрузки я больше не смог смонтировать раздел btrfs. Однако ни одно из упомянутых здесь решений не может решить эту проблему.

Что мне удалось исправить, так это обновление ядра с 3.10 до 3.12. После перезагрузки раздел btrfs может быть снова смонтирован.

Ответ Питера решил проблему для меня, хотя и не в Ubuntu. У меня был /home раздел btrfs'd, который, конечно, был поврежден. Система не будет загружаться, потому что она была включена fstab. Я вошел в режим обслуживания, хэшировал строку с этим разделом и нормально загрузился (у меня был запасной раздел ext4, который я мог использовать как /home).

Я смонтировал раздел вручную с помощью следующей команды:

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3 и фактически смог сохранить мои данные. Хотя это не займет много времени, чтобы установить его. Так что СПАСИБО Петру.

Монтирование при загрузке с использованием параметров монтирования root fs:

rootflags=recovery,nospace_cache

или

rootflags=recovery,nospace_cache,clear_cache

Полный список параметров монтирования btrfs должен быть здесь https: // btrfs. wiki.kernel.org/index.php/Mount_options и другие вещи также могут быть полезны, такие как noatime, nodatacow (исправлена ​​ошибка в ядре для меня, дающая мне возможность копировать мои файлы).

Добавьте его в свой grub.cfg / menu.lst или введите его при загрузке.

Материал из nospace_cache сделает вещи ужасно медленными. Просто загрузитесь, подождите (долго), выключите и загрузитесь как обычно.

У меня было то же самое несколько дней назад, и вышеописанное исправило это. Но также после этого были некоторые космические проблемы ... сообщаемое пространство не на 100%, но оно все еще может сказать, что из космоса.

==

Я думаю, вы также можете добавить те же опции в свой fstab, например:

UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0  
 2

Если вы пытались восстановить каталог / home, смонтированный над разделом с UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf.

Самый легкий путь

btrfs-zero-log /dev/sda5

Ваше получение той проблемы, потому что транзакция (пишут или удаляют) застревает в журнале журнала и диске, не соответствует ему.

Как это работает:

Таким образом, когда данные записаны 1-й ее записанный для журналирования затем к диску (или в то же время, но журнал просто сохраняет метаданные о предстоящей записи - не уверенный... нуждаются в большем количестве исследования в области той части)...

Во всяком случае, если Вы выключаете систему посреди этого, пишут/удаляют или делают что-то отклонения система (демонтируйте USB, который содержит Вашу btrfs точку монтирования), затем когда это возвратится, то монтирование не будет работать, это перестанет работать (dmesg, и btrfsck покажет Вам ошибки более подробно)...

Рассмотрение dmesg Вы будет видеть те те же транзитные сообщения.

Вы будете видеть что-то вроде этого:

parent transid verify failed on 109973766144 wanted 1823 found 1821

Это означает, что btrfs хотел transif 1826 (Который был на журнале), но на диске это видело 1821. Таким образом, диск был 2 транзакциями далеко от того, чтобы быть в синхронизации с журналом. Я лично рискнул бы brtfs-zero-log здесь просто потому что его только 2 транзакции. Но быть 100%-м сейфом, если это - Ваши единственные данные (по тому, как, если у Вас есть критические данные, Вы никогда не должны иметь только 1 копии его, всегда иметь копию/резервное копирование в безопасном другом месте - обвинение создателей btrfs не выровняло бы по ширине против людей, собственное отсутствие ответственности не наличия резервного копирования - btrfs не является решением для резервного копирования, это - файловая система - ничто еще не истинное решение для резервного копирования помимо наличия копии его, где - даже четность или зеркальные диски, истинное резервное копирование находится где-нибудь под землей в Альпах, в то время как его активная копия находится в Вашем офисе в Техасе),

parent transid verify failed on 31302336512 wanted 62455 found 62456

Здесь журнал желает 62455, но диск является тем вперед в 62 456, таким образом, в Вашем случае я просто очистил бы журнал. Журнал не обновил на этот раз. Снова я сказал Вам поединок, являющийся безопасной вещью, если ее Ваши единственные данные и ее мега критическое (позор Вам), и я сделаю ниже операций сначала для сейфа.

Выполнение 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 (дамп системы, поскольку я понимаю, что это - resumeable операция, однако это продолжает просить Y или y время от времени, так наблюдайте вывод),

btrfs restore /dev/sda5 /USB

Затем, когда безопасный (когда восстановление btrfs сделано) делают btrfs-zero-log, если это - успешная операция, Вы просто потратили впустую много времени, создав резервную копию Вашей системы (но если не успешный, Вы просто сохранили свою задницу),

Можно выполнить экран сначала

screen /bin/bash

btrfs restore /dev/sda5 /USB

ЭКРАННОЕ ПРИМЕЧАНИЕ СТОРОНЫ

Для отсоединения (команда будет все еще работать): УПРАВЛЯЙТЕ-a затем вводят ": отсоединитесь" без кавычек, затем нажимают ENTER

Другой способ отсоединиться: Затем близко из шпаклевки или Ваш терминал и это отсоединятся (команда / восстановление будет все еще работать).

Для выяснения его просто экранируйте назад к нему:

screen -x

экран-x присоединит к сессиям, даже если отдельный, и в отличие от-h скажет, то он уже присоединит даже если его приложенный также),

Если Вы будете иметь несколько экранов, экранируете-x, то скажет, что необходимо быть более конкретными для присоединения к сессии:

screen -ls

ls для списка все сессии, легкие помнить это.

для наблюдения PID, можно также сделать это:

ps aux | grep screen

После того как Вы узнаете свой PID, затем выполняете экран как это:

screen -x PID

Это присоединит к определенной сессии. У Вас может быть несколько sessions/puttys, присоединенные к тому же экрану (они произведут тот же текст, можно ввести команды в одной, и они будут зеркально отражены на другой шпаклевке),