On 27 February 2017 at 18:43, Andrei Borzenkov <arvidjaar(a)gmail.com> wrote:
26.02.2017 14:38, Richard Brown пишет:
Good. So as you appear to be expert in repairng corrupted btrfs - after
reboot I get "parent transid failed". Without doing anything in between
at all - I just booted and after 10 minutes did "reboot". Of course,
even grub does not load now as it itself is located on btrfs and cannot
read its modules.
Your suggestion? OK I must not use btrfcsk. What I *must* use now?
The below are the steps I would recommend for ANY btrfs issue, smart
people reading dmesg or syslog can probably figure out which of these
steps they'd need to skip to in order to fix their particular problem.
Step 1 - boot to a suitable alternative system, such as a different
installation of openSUSE, a liveCD, or an openSUSE installation DVD.
The installation DVD for the version of openSUSE you are running is
usually the best choice as it will certainly use the same kernel/btrfs
Step 2 - Go to a suitable console and make sure you do the below as root
Step 3 - Try to mount your partition to /mnt, just to confirm it's
really broken (eg. "mount /dev/sda1 /mnt")
Step 4 - If it mounts - are you sure it's broken? if Yes - run "btrfs
scrub start /mnt" to scrub the system, and "btrfs scrub status /mnt"
to monitor it
Step 5 - If it doesn't mount, try to scrub the device just in case it
works (eg. "btrfs scrub start /dev/sda1" and "btrfs scrub status
/dev/sda1" to monitor). Try mounting, if yes, you're fixed.
Step 6 - If scrubbing is not an option or does not resolve the issue
then try "mount -o usebackuproot" instead (eg. "mount -o usebackuproot
All of the above steps are considered safe and should make no
destructive changes to disk, and have fixed every filesystem issue
I've had on btrfs in the last 5 years
Full disk issues need a different approach (basically, delete stuff
;)) documented here:
If the above doesn't fix things for you, you can continue with the
below steps but the situation is serious enough to justify a bug
Step 7 - Run "btrfs check <device>" (eg. "btrfs check
This isn't going to help, but save the log somewhere, it will be
useful for the bug report.
Step 8 - Seriously consider running "btrfs restore <device> <somewhere
to copy data>" (eg. "btrfs restore /dev/sda1 /mnt/usbdrive"). This
won't fix anything but it will scan the filesystem and recover
everything it can to the mounted device. This especially useful if
your btrfs issues are actually caused by failing hardware and not
Step 9 - Run "btrfs rescue super-recover <device>" (eg. "btrfs
super-recover /dev/sda1"). Then try to mount the device normally. If
it works, stop going.
Step 10 - Run "btrfs rescue zero-log <device>" (eg. "btrfs rescue
zero-log /dev/sda1"). Then try to mount the device normally. If it
works, stop going.
Step 11 - Run "btrfs rescue chunk-recover <device>" (eg. "btrfs
chunk-recover /dev/sda1"). This will take a LONG while. Then try to
mount the device normally. If it works, stop going.
Step 12 - Don't just consider it this time, don't be an idiot, run
"btrfs restore <device> <somewhere to copy data>" (eg. "btrfs
Step 13 - Seriously, don't be an idiot, use btrfs restore
The above tools had a small chance of making unwelcome changes, but
now you're in the seriously suicidal territory, do not do the
following unless you're prepared to accept the consequences of your
Step 14 - Now, ONLY NOW, try btrfsck aka "btrfs check --repair
<device>" (eg. "btrfs check --repair /dev/sda1")
There, I'm very confident the above will help you Andrei, and for
everyone else, can we please bury the nonsense that btrfs is lacking
when it comes to repair and recovery tools?
You have scrub which is safe for day to day use, the perfectly safe
usebackuproot mount option, and the various "btrfs rescue" commands
which are only moderately worrying compared to the practical Russian
roulette which is "btrfs check"
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org