Re: BTRFS unable to mount after one failed disk in RAID 1

[Chris Murphy <lists@colorremedies.com>]

On Tue, Aug 20, 2019 at 1:42 PM Daniel Clarke <dan@e-dan.co.uk> wrote:

> ~$ btrfs check --init-extent-tree /dev/sdc1
> warning, device 2 is missing
> Checking filesystem on /dev/sdc1
> UUID: 70a651ab-4837-4891-9099-a6c8a52aa40f
> Creating a new extent tree
> bytenr mismatch, want=1058577645568, have=0
> Error reading tree block
> error pinning down used bytes
> ERROR: attempt to start transaction over already running one
> extent buffer leak: start 1768503115776 len 16384


This very likely has made the problem much worse and will prevent data
recovery, especially given the old version of btrfs-progs you were
using. This option is explicitly listed in the man page as a dangerous
option, *and* it comes with a note:

               Do not use unless you know what you’re doing.

That you used this option without first trying to use 'degraded' mount
option (or at least you didn't say you tried it), suggests you don't
know what you're doing.

Otherwise, had you not used this option I'd have suggested the following:

> ~$ mount -t btrfs -o ro,usebackuproot,compress=zstd /dev/sdc1 /mnt/maindisk
> mount: /mnt/maindisk: wrong fs type, bad option, bad superblock on
> /dev/sdc1, missing codepage or helper program, or other error.

I would use mount -o ro,degraded, check the kernel messages, see if
this mounts and your latest files are intact, make a backup of
important files while you have the chance. If this does not mount then
try:

mount -o ro,degraded,norecovery   ##same as nologreplay

>~$ btrfs --version
>btrfs-progs v4.15.1

Before proceeding further I recommend newer btrfs-progs, that's old
enough I'm not totally certain of the 'btrfs replace' status - it's
probably fine, I just can't vouch for it because a lot of bugs have
been fixed since this version. You didn't mention kernel but since
you're using zstd it must be 4.14 or newer, and that should be safe to
proceed, but I'll recommend 5.1.20+, or the newest long term kernel
you can use.

Next,

mount -o degraded
## or if already ro mounted
mount -o remount,rw,degraded

Choose one:

##replacement device is same size or bigger than the failed drive
btrfs replace start
btrfs fi resize X:max

##replacement device is smaller than the failed drive
brtfs dev add
btrfs dev rem missing

Of course you need to read the man page and ensure you specify the
correct devices to add and remove (the failed device can be referred
to as "missing" without quotes) and proper mount points. Using replace
is faster than dev add + dev rem, but filesystem resize is not
included. Where btrfs dev add + dev rem will resize the file system
(twice actually).

It should be safe to just immediately mount degraded and start one of
the replacement processes, while you do your backup refresh. But I'm
very conservative and tend to start with an ro,degraded mount, that
way if there are problems I have made very few changes to the file
system and I also have decent backups.

-- 
Chris Murphy