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.dun...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
