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

Установка для 12.04 продолжала завершаться сбоем, и решение состояло в том, чтобы установщик игнорировал раздел btrfs, который я ранее использовал для /home.

Теперь, когда он установлен, я пытался заставить его смонтировать раздел btrfs, чтобы я мог получить доступ к моим 70 ГБ файлам. Он не будет монтироваться, и btrfsck выдает ошибки со следующими тремя строками:

parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456

Может кто-нибудь подсказать, как заставить работать этот раздел? Я читал в Интернете, что, вероятно, я могу восстановить данные с помощью btrfs-restore, но я нигде не могу найти эту программу.

10
задан 30 June 2012 в 13:37

46 ответов

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

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

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

1
ответ дан 25 July 2018 в 18:15

Самый простой способ

btrfs-zero-log /dev/sda5

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

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

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

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

Посмотрев на dmesg, вы увидите те же самые мимолетные сообщения.

Вы увидите что-то вроде this:

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

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

чтобы увидеть PID, вы также можете сделать это:

ps aux | grep screen

Однажды Вы узнаете свой PID, затем запустите экран следующим образом:

screen -x PID

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

8
ответ дан 25 July 2018 в 18:15

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

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

0
ответ дан 25 July 2018 в 18:15

Монтировать при загрузке, используя параметры монтирования 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.

6
ответ дан 25 July 2018 в 18:15
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

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

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

0
ответ дан 25 July 2018 в 18:15

Самый простой способ

btrfs-zero-log /dev/sda5

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

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

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

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

Посмотрев на dmesg, вы увидите те же самые мимолетные сообщения.

Вы увидите что-то вроде this:

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

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

чтобы увидеть PID, вы также можете сделать это:

ps aux | grep screen

Однажды Вы узнаете свой PID, затем запустите экран следующим образом:

screen -x PID

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

8
ответ дан 31 July 2018 в 10:50

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

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

0
ответ дан 31 July 2018 в 10:50
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

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

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

0
ответ дан 31 July 2018 в 10:50

Монтировать при загрузке, используя параметры монтирования 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.

6
ответ дан 31 July 2018 в 10:50

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

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

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

1
ответ дан 31 July 2018 в 10:56

Самый простой способ

btrfs-zero-log /dev/sda5

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

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

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

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

Посмотрев на dmesg, вы увидите те же самые мимолетные сообщения.

Вы увидите что-то вроде this:

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

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

чтобы увидеть PID, вы также можете сделать это:

ps aux | grep screen

Однажды Вы узнаете свой PID, затем запустите экран следующим образом:

screen -x PID

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

8
ответ дан 31 July 2018 в 10:56

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

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

0
ответ дан 31 July 2018 в 10:56
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

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

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

0
ответ дан 31 July 2018 в 10:56

Монтировать при загрузке, используя параметры монтирования 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.

6
ответ дан 31 July 2018 в 10:56

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

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

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

1
ответ дан 31 July 2018 в 11:55

Самый простой способ

btrfs-zero-log /dev/sda5

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

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

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

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

Посмотрев на dmesg, вы увидите те же самые мимолетные сообщения.

Вы увидите что-то вроде this:

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

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

чтобы увидеть PID, вы также можете сделать это:

ps aux | grep screen

Однажды Вы узнаете свой PID, затем запустите экран следующим образом:

screen -x PID

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

8
ответ дан 31 July 2018 в 11:55

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

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

0
ответ дан 31 July 2018 в 11:55
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

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

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

0
ответ дан 31 July 2018 в 11:55

Монтировать при загрузке, используя параметры монтирования 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.

6
ответ дан 31 July 2018 в 11:55

Самый простой способ

btrfs-zero-log /dev/sda5

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

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

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

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

Посмотрев на dmesg, вы увидите те же самые мимолетные сообщения.

Вы увидите что-то вроде this:

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

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

чтобы увидеть PID, вы также можете сделать это:

ps aux | grep screen

Однажды Вы узнаете свой PID, затем запустите экран следующим образом:

screen -x PID

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

8
ответ дан 2 August 2018 в 00:28

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

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

0
ответ дан 2 August 2018 в 00:28

Монтировать при загрузке, используя параметры монтирования 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.

6
ответ дан 2 August 2018 в 00:28
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

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

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

0
ответ дан 2 August 2018 в 00:28

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

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

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

1
ответ дан 4 August 2018 в 15:57

Самый простой способ

btrfs-zero-log /dev/sda5

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

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

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

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

Посмотрев на dmesg, вы увидите те же самые мимолетные сообщения.

Вы увидите что-то вроде this:

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

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

чтобы увидеть PID, вы также можете сделать это:

ps aux | grep screen

Однажды Вы узнаете свой PID, затем запустите экран следующим образом:

screen -x PID

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

8
ответ дан 4 August 2018 в 15:57

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

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

0
ответ дан 4 August 2018 в 15:57
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

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

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

0
ответ дан 4 August 2018 в 15:57

Монтировать при загрузке, используя параметры монтирования 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.

6
ответ дан 4 August 2018 в 15:57

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

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

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

1
ответ дан 6 August 2018 в 00:35

Монтировать при загрузке, используя параметры монтирования 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.

6
ответ дан 6 August 2018 в 00:35

Другие вопросы по тегам:

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