linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Issues while doing btrfs delete missing in raid6
Date: Mon, 20 Nov 2017 15:13:48 +0800	[thread overview]
Message-ID: <3bc72dbb-7d3d-fa1c-8302-f789c41ea1a4@gmx.com> (raw)
In-Reply-To: <20171120014344.7a5d8bd2@Vantage.cJ>


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



On 2017年11月20日 14:43, Jérôme Carretero wrote:
> Hi,
> 
> 
> While doing a test (to evaluate drives), where I'm filling a bunch of
> drives in RAID6, one of the disks failed in the process.
> (System with v4.14 / ECC).
> I remounted the array in degraded, launched a "btrfs delete missing"
> as I have no replacement device.
> 
> The command (takes ages and) fails with:
>  ERROR: error removing device 'missing': Input/output error
> 
> and klog says:
> 
>  [631517.263313] BTRFS info (device dm-18): relocating block group 1411883335680 flags data|raid6
>  [631547.556527] btrfs_print_data_csum_error: 151 callbacks suppressed
>  [631547.556530] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559653376 csum 0x2e827bb4 expected csum 0xda9c34d6 mirror 2

Root -9 means it's a data reloc tree. So its ino number is not real
inode number.

To delete it, you need to  calculate the offset into bytenr, then find
the owner.

>  [631547.562727] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559657472 csum 0x6722cd32 expected csum 0x3ca2ce6f mirror 2
>  [631547.562730] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559661568 csum 0x90368636 expected csum 0xf55a0410 mirror 2
>  [631547.562732] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559665664 csum 0x3e38aeb2 expected csum 0x6c80a970 mirror 2
>  [631547.562746] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559669760 csum 0x77d73f2d expected csum 0xe62cfbe8 mirror 2
>  [631547.562747] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559673856 csum 0xb03d1632 expected csum 0xe9a3f0e6 mirror 2
>  [631547.562756] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559677952 csum 0xeea04377 expected csum 0x8819aaf7 mirror 2
>  [631547.562758] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559682048 csum 0xe46ab546 expected csum 0xacc16686 mirror 2
>  [631547.562775] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559690240 csum 0x956a74d7 expected csum 0x99e29858 mirror 2
>  [631547.562788] BTRFS warning (device dm-18): csum failed root -9 ino 1177 off 3559686144 csum 0xb09a35ae expected csum 0x5f61fa99 mirror 2
> 
> Since this is RAID6, I wasn't expecting to not be able to recover
> from a checksum issue,

Currently btrfs RAID6 can't ensure recovered data to match its csum.

That's to say, if some other error, like real data corruption in another
disk, in theory RAID6 could still recover it, but the truth is, it may
use the corrupted disk to recover, resulting back checksum.

Thanks,
Qu

> also it's not very practical to bail out on the first
> error of this kind during a delete... the offending blocks could be
> left as is.
> 
> I then try to work around the issue by removing the offending file
> (yes it's a test, but filling the drives takes a lot of time),
> finding it with "btrfs inspect-internal inode-resolve 1177", and somehow:
>  ERROR: ino paths ioctl: No such file or directory
> 
> 
> Regards,
> 


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

  parent reply	other threads:[~2017-11-20  7:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-20  6:43 Issues while doing btrfs delete missing in raid6 Jérôme Carretero
2017-11-20  6:54 ` Jérôme Carretero
2017-11-20  7:13 ` Qu Wenruo [this message]
2017-11-20 21:57 ` Duncan
2017-11-21  1:06   ` Jérôme Carretero

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=3bc72dbb-7d3d-fa1c-8302-f789c41ea1a4@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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).