Re: btrfs scrub failing

[Martin Steigerwald <martin@lichtvoll.de>]

Am Samstag, 2. Januar 2016, 11:35:51 CET schrieb Martin Steigerwald:
> Am Freitag, 1. Januar 2016, 20:04:43 CET schrieb John Center:
> > Hi Duncan,
> > 
> > On Fri, Jan 1, 2016 at 12:05 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > > John Center posted on Fri, 01 Jan 2016 11:41:20 -0500 as excerpted:
> > >> If this doesn't resolve the problem, what would you recommend my next
> > >> steps should be?  I've been hesitant to run too many of the
> > >> btrfs-tools,
> > >> mainly because I don't want to accidentally screw things up & I don't
> > >> always know how to interpret the results. (I ran btrfs-debug-tree,
> > >> hoping something obvious would show up.  Big mistake. 😋)
> > > 
> > > LOLed at that debug-tree remark.  Been there (with other tools) myself.
> > > 
> > > Well, I'm hoping someone who had the problem can confirm whether it's
> > > fixed in current kernels (scrub is one of those userspace commands
> > > that's
> > > mostly just a front-end to the kernel code which does the real work, so
> > > kernel version is the important thing for scrub).  I'm guessing so, and
> > > that you'll find the problem gone in 4.3.
> > > 
> > > We'll cross the not-gone bridge if we get to it, but again, if the other
> > > people who had the similar problem can confirm whether it disappeared
> > > for
> > > them with the new kernel, it would help a lot, as there were enough such
> > > reports that if it's the same problem and still there for everyone
> > > (which
> > > I doubt as I expect there'd still be way more posts about it if so, but
> > > confirmation's always good), nothing to do but wait for a fix, while if
> > > not, and you still have your problem, then it's a different issue and
> > > the
> > > devs will need to work with you on a fix specific to your problem.
> > 
> > Ok, I'm at the next bridge. :-(  I upgraded the kernel to 4.4rc7 from
> > the Ubuntu Mainline archive & I just ran the scrub:
> > 
> > john@mariposa:~$ sudo /sbin/btrfs scrub start -BdR /dev/md125p2
> > ERROR: scrubbing /dev/md125p2 failed for device id 1: ret=-1, errno=5
> > (Input/output error)
> > scrub device /dev/md125p2 (id 1) canceled
> > scrub started at Fri Jan  1 19:38:21 2016 and was aborted after 00:02:34
> > data_extents_scrubbed: 111031
> > tree_extents_scrubbed: 104061
> > data_bytes_scrubbed: 2549907456
> > tree_bytes_scrubbed: 1704935424
> > read_errors: 0
> > csum_errors: 0
> > verify_errors: 0
> > no_csum: 1573
> > csum_discards: 0
> > super_errors: 0
> > malloc_errors: 0
> > uncorrectable_errors: 0
> > unverified_errors: 0
> > corrected_errors: 0
> > last_physical: 4729667584
> > 
> > I checked dmesg & this appeared:
> > 
> > [11428.983355] BTRFS error (device md125p2): parent transid verify
> > failed on 241287168 wanted 33554449 found 17
> > [11431.028399] BTRFS error (device md125p2): parent transid verify
> > failed on 241287168 wanted 33554449 found 17
> > 
> > Where do I go from here?
> 
> These and the other errors point at an issue with the filesystem structure.
> 
> As I never had to deal with that, I can only give generic advice:
> 
> 1) Use latest stable btrfs-progs.
> 
> 2) Umount the filesystem and run
> 
> btrfs check (maybe with -p)
> 
> When it finds some errors, proceed with the following steps:
> 
> Without --repair or some of the other options that modify things it is read
> only.
> 
> 3) If you can still access all the files, first thing to do is: rsync or
> otherwise backup them all to a different location, before attempting
> anything to repair the issue.
> 
> 4) If you can´t access some files, you may try to use btrfs restore for
> restoring them.
> 
> 5) Then, if you made sure you have an up-to-date backup run
> 
> btrfs --repair

Before doing that, review:

https://btrfs.wiki.kernel.org/index.php/Btrfsck

to learn about other options.

Thanks,
-- 
Martin