On 24.07.2011 22:44, Jan Schubert wrote: > On 07/24/2011 03:31 PM, Jan Schmidt wrote: >> >> Yes, please check if that error solely depends on the state of your file >> system (which is what I expect). Please try another scrub while the >> system is as idle as you get it (also consider daemon processes, cron >> jobs etc.). > > > Jan, doing a new scrub using a clean kernel (without your patchset) the > system did not crash. I'm back to my 2211 uncorrectable errors now and > dmesg shows also the (some?) corresponding inodes: > > btrfs: use lzo compression > btrfs: enabling disk space caching > btrfs: use ssd allocation scheme > Adding 4194300k swap on /dev/sda3. Priority:-1 extents:1 across:4194300k SS > btrfs: unable to fixup at 182245502976 > btrfs: unable to fixup at 182245507072 > btrfs: unable to fixup at 182245511168 > btrfs: unable to fixup at 182245515264 > btrfs: unable to fixup at 182245519360 > btrfs: unable to fixup at 182245523456 > btrfs: unable to fixup at 182245527552 > btrfs: unable to fixup at 182245531648 > btrfs: unable to fixup at 182245535744 > btrfs: unable to fixup at 182245539840 > > scrub status for 03201fc0-7695-4468-9a10-f61ad79f23ca > scrub started at Sun Jul 24 22:13:09 2011 and finished after 787 > seconds > total bytes scrubbed: 173.92GB with 2211 errors > error details: csum=2211 > corrected errors: 0, uncorrectable errors: 2211
Okay, it's good that it's persistent. > So there might be an issue with your patch concerning the kernel oops? Yes, that seems quite likely. > Any chance to resolve the inodes to affected files manualy? That's cumbersome, but you can do it using the information contained in the debug-tree output. But I'd rather find the bug I must have introduced :-) > Did I mention that I just did apply your patches 1 to 3 from your patch > set as suggested by you in the mailing list? You did. And yes, that hasn't been tested as much as applying the whole patch set. I just double checked it's working for me, though. I don't expect it makes a difference if you apply all the patches. > Are you interested in btrfs-debug-tree anyway? Absolutely, yes. Alternatively, if you have a lot of bandwidth and no private data in your file system, it would be even more helpful if you put the whole file system somewhere. But the btrfs-debug-tree output would help a lot, too. -Jan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
