Re: How to recover from btrfs scrub errors? (uncorrectable errors, checksum error at logical)
I never got a reply to this thread, but I am not replying to myself in case somebody has the same issue and is reading the archive: The problem went away after: - deleted all snapshots as they seemed to slow down btrfs I/O so much that simple commands like rm and rsync were unusable - replaced the disk that had the corrupted file (just in case - smartctl did not indicate any disk failures) with btrfs replace - rsynced files from another location to this filesystem so that the corrupted files got overwritten Now btrfs scrub does not find any corruption anymore and the filesystem I/O speed is usable, though still slower than what it used to be in the past. ma 15. lokak. 2018 klo 10.50 Otto Kekäläinen (o...@seravo.fi) kirjoitti: > > Hello! > > I am trying to figure out how to recover from errors detected by btrfs scrub. > > Scrub status reports: > > scrub status for 4f4479d5-648a-45b9-bcbf-978c766aeb41 > scrub started at Mon Oct 15 10:02:28 2018, running for 00:35:39 > total bytes scrubbed: 791.15GiB with 18 errors > error details: csum=18 > corrected errors: 0, uncorrectable errors: 18, unverified errors: 0 > > Kernel log contains lines like > > BTRFS warning (device dm-8): checksum error at logical 7351706472448 on dev > /dev/mapper/disk6tb, sector 61412648, root 12725, inode 152358265, > offset 483328: > path resolving failed with ret=-2 > > I've tried so far: > - deleting the files (when path is visible) > - overwriting the files with new data > - changed disk (with btrfs replace) > > The checksum errors however persist. > How do I get rid of them? > > > The files are logs and other non-vital information. I am fine by > deleting the corrupted files. It is OK to recover so that I loose a > few gigabytes of data, but not the entire filesystem. > > Setup is a multi-disk btrfs filesystem, data single, metadata RAID-1 > Mounted with: > > /dev/mapper/wdc3td on /data type btrfs > (rw,noatime,compress=lzo,space_cache,subvolid=5,subvol=/) > > I've read lots of online sources on the topic but none of these help > me on how to recover from the current state: > > https://btrfs.wiki.kernel.org/index.php/Btrfsck > http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html > https://wiki.archlinux.org/index.php/Identify_damaged_files#Find_damaged_files -- Otto Kekäläinen CEO Seravo +358 44 566 2204 Follow me at @ottokekalainen
How to recover from btrfs scrub errors? (uncorrectable errors, checksum error at logical)
Hello! I am trying to figure out how to recover from errors detected by btrfs scrub. Scrub status reports: scrub status for 4f4479d5-648a-45b9-bcbf-978c766aeb41 scrub started at Mon Oct 15 10:02:28 2018, running for 00:35:39 total bytes scrubbed: 791.15GiB with 18 errors error details: csum=18 corrected errors: 0, uncorrectable errors: 18, unverified errors: 0 Kernel log contains lines like BTRFS warning (device dm-8): checksum error at logical 7351706472448 on dev /dev/mapper/disk6tb, sector 61412648, root 12725, inode 152358265, offset 483328: path resolving failed with ret=-2 I've tried so far: - deleting the files (when path is visible) - overwriting the files with new data - changed disk (with btrfs replace) The checksum errors however persist. How do I get rid of them? The files are logs and other non-vital information. I am fine by deleting the corrupted files. It is OK to recover so that I loose a few gigabytes of data, but not the entire filesystem. Setup is a multi-disk btrfs filesystem, data single, metadata RAID-1 Mounted with: /dev/mapper/wdc3td on /data type btrfs (rw,noatime,compress=lzo,space_cache,subvolid=5,subvol=/) I've read lots of online sources on the topic but none of these help me on how to recover from the current state: https://btrfs.wiki.kernel.org/index.php/Btrfsck http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html https://wiki.archlinux.org/index.php/Identify_damaged_files#Find_damaged_files
Re: btrfs-check: Fix bitflipped keys from bad RAM
2016-06-28 23:11 GMT+03:00 Otto Kekäläinen <o...@seravo.fi>: > Hello! > > A patch with this subject was submitted in May 2014: > http://www.spinics.net/lists/linux-btrfs/msg33777.html > > I don't see it among any of the ~360 open issues at > https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED=btrfs > > Unless somebody objects, I'll file it as a NEW issue with patch. > > > I think the work done by Hugo Mills for this one is important and it > would be a pity if those patches were forgotten. It is one of those > things where btrfs could outperform zfs, which has not bitflip > recovery. Btrfs could have one, and it would be great. > > I personally came across a machine with a bitflipped index and I would > love to test these patches. I am however reluctant to invest time in > it if there is no issue in the bug tracker and no visible progress. > Without proper tracking all debugging/feedback would go in vain. I eventually went ahead and filed this as https://bugzilla.kernel.org/show_bug.cgi?id=17447 It would be very cool if the bitflip recovery patch was merged. It is one of those things where btrfs could outperform zfs. -- 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
btrfs-check: Fix bitflipped keys from bad RAM
Hello! A patch with this subject was submitted in May 2014: http://www.spinics.net/lists/linux-btrfs/msg33777.html I don't see it among any of the ~360 open issues at https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED=btrfs Unless somebody objects, I'll file it as a NEW issue with patch. I think the work done by Hugo Mills for this one is important and it would be a pity if those patches were forgotten. It is one of those things where btrfs could outperform zfs, which has not bitflip recovery. Btrfs could have one, and it would be great. I personally came across a machine with a bitflipped index and I would love to test these patches. I am however reluctant to invest time in it if there is no issue in the bug tracker and no visible progress. Without proper tracking all debugging/feedback would go in vain. -- 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
