linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: "Otto Kekäläinen" <otto@seravo.fi>, linux-btrfs@vger.kernel.org
Subject: Re: How to recover from btrfs scrub errors? (uncorrectable errors, checksum error at logical)
Date: Mon, 15 Oct 2018 16:30:24 +0800	[thread overview]
Message-ID: <eba5de6f-535a-0f5d-e415-9cd622d71b36@gmx.com> (raw)
In-Reply-To: <CAHj_TLCsG52NUJf6DbKCO9iQ6Fr2-jOUAsfHs=_UM_LJBYtdMA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2508 bytes --]



On 2018/10/15 下午3:50, Otto Kekäläinen wrote:
> 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)

Please ensure there are no other subvolumes/snapshots containing the
same file or reflink to it.

If path is not visible, please use the root and inode number to locate
the culprit file.
"find" command support to search using inode number.
And "btrfs subvolume list" command will show the subvolume number.

Also it's recommended to sync the fs before scrub, in case culprit inode
only get orphaned but not deleted from disk.

> - overwriting the files with new data

If you're only overwriting the culprit sector, it could get CoWed and
the original data extent is still there.

You need to ensure the old data is not referred by any other root/inode.
Please ensure there is no reflink/snapshot first.

Then delete the file or overwrite the whole culprit file.

Thanks,
Qu

> - 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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-10-15  8:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15  7:50 How to recover from btrfs scrub errors? (uncorrectable errors, checksum error at logical) Otto Kekäläinen
2018-10-15  8:30 ` Qu Wenruo [this message]
2018-10-22  6:29 ` Otto Kekäläinen
2018-10-22  6:53   ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eba5de6f-535a-0f5d-e415-9cd622d71b36@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=otto@seravo.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).