On Thu, Sep 5, 2019 at 1:18 PM Edmund Urbani <edmund.urb...@liland.com> wrote: > > > On 04.09.2019 07:36, Chris Murphy wrote: > > > >>> > >>>> I have tried all the mount / restore options listed here: > >>>> https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-543490 > >>> Good. Stick with ro attempts for now. Including if you want to try a > >>> newer kernel. If it succeeds to mount ro, my advice is to update > >>> backups so at least critical information isn't lost. Back up while you > >>> can. Any repair attempt makes changes that will risk the data being > >>> permanently lost. So it's important to be really deliberate about any > >>> changes. > >> I'll let you know, when I have the new kernel up and running. > > I think you should have all the original drives installed, and try to > > mount -o ro first. And if that doesn't work, try -o ro,degraded, and > > then we'll just have to see which drive it doesn't like. > > Things are finally looking up. I have replaced both sdb and sdf with > ddrescue'd copies. sdb had some 10MB bad sectors and sdf 8KB which could > not be recovered. > > I am now able to mount the volume again. :) > > btrfsck /dev/sda1 > > Opening filesystem to check... > Checking filesystem on /dev/sda1 > UUID: 108df6ea-2846-4a88-8a50-61aedeef92b4 > [1/7] checking root items > checksum verify failed on 34958760591360 found E4E3BDB6 wanted 00000000 > checksum verify failed on 34958760591360 found E4E3BDB6 wanted 00000000 > parent transid verify failed on 34958760591360 wanted 3331734 found 1544337 > checksum verify failed on 34958760591360 found 04DEBA71 wanted B9FBE54D > checksum verify failed on 34958760591360 found 04DEBA71 wanted B9FBE54D > bad tree block 34958760591360, bytenr mismatch, want=34958760591360, > have=27967614209536 > ERROR: failed to repair root items: Input/output error > > Anyway, I am about to mount it read-only again to try and backup a few > things. And once I am done with that, should I run btrfs scrub?
Did it mount with ro alone, or did you need ro,degraded? I'm a little confused by the i/o error, which I'd expect will also produce a message at the same time in dmesg that will hint what the nature of the i/o error is. That suggests some kind of hardware issue still exists, even if it is an uncorrectable sector read error. For sure rw mounted scrubs can fix those thing, if enough redundancy exists, and those copies aren't also corrupt. But I'm off hand not sure whether 'btrfs check --repair' can fixup bad sectors like scrub can. Anyway, I suggest 'btfs check --repair' is a last resort, no matter the version of btrfs-progs. 'btrfs check' alone is safe. So in order: * you've done these *dmesg *btrfs check --readonly ##safe, makes no changes, maybe gives a hint of the problem *mount -o ro *mount -o ro,degraded mount -o rw ## all devices available mount -o rw,degraded I'm not sure a read only scrub helps much. It might be interesting? What you really want is to be able to mount rw with all devices, and then scrub. But even rw,degraded is better, because you must be rw mounted to make scrub repairs, and also to do device replacements. I personally would not do a degraded scrub, because that scrub requires reading the whole volume. If you're going to read the whole volume anyway, you might as well rebuild the bad/missing device, so that you can more quickly get back to undegraded/normal RAID6 operation. If you can only mount 'rw,degraded' we need to see 'btrfs fi show' and the kernel messages for the failed mount and the successful degraded mount, so we can figure out what devices are affected, maybe why, and then what the next step is. Anyone know if latest kernel and progs now reliably supports 'btrfs replace' for RAID6? For a bit it was recommended to do it the old way, with 'btrfs device add' followed by 'btrfs device delete'. Main difference for the user is that 'replace' requires that the replacement drive is at least as big (in bytes) as the one being replaced and also that 'replace' will not resize the volume after replacement is finished, that has to be done manually. Otherwise I think it's preferred? -- Chris Murphy
