Hi Christoph,
Since I'm still digging the unexpected corruption (although without much
progress yet), would you please describe how the corruption happens?
In my current investigation, btrfs is indeed bullet-proof, (unlike my
original assumption) using newer dm-log-writes tool.
But free space
And you have any other ideas on how to dubs that filesystem? Or at least backup
as much as possible?
Thanks, Chris.
--
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
On 21.02.2018 19:18, Christoph Anton Mitterer wrote:
> e8f1bc1493855e32b7a2a019decc3c353d94daf6
>
> That bug... When was that introduced and how can I find out whether an fs was
> affected/corrupted by this? Cause I've mounted and wrote to some extremely
> important (to me) fs recently.
e8f1bc1493855e32b7a2a019decc3c353d94daf6
That bug... When was that introduced and how can I find out whether an fs was
affected/corrupted by this? Cause I've mounted and wrote to some extremely
important (to me) fs recently.
Thanks, Chris.
--
To unsubscribe from this list: send the line
A scrub now gave:
# btrfs scrub start -Br /dev/disk/by-label/system
ERROR: scrubbing /dev/disk/by-label/system failed for device id 1: ret=-1,
errno=5 (Input/output error)
scrub canceled for b6050e38-716a-40c3-a8df-fcf1dd7e655d
scrub started at Wed Feb 21 17:42:39 2018 and was aborted
Spurious corruptions seem to continue
[ 69.688652] BTRFS critical (device dm-0): unable to find logical
4503658729209856 length 4096
[ 69.688656] BTRFS critical (device dm-0): unable to find logical
4503658729209856 length 4096
[ 69.688658] BTRFS critical (device dm-0): unable to find
Interestingly, I got another one only within minutes after the scrub:
Feb 21 15:23:49 heisenberg kernel: BTRFS warning (device dm-0): csum failed
root 257 ino 7703 off 56852480 csum 0x42d1b69c expected csum 0x3ce55621 mirror 1
Feb 21 15:23:52 heisenberg kernel: BTRFS warning (device dm-0): csum
Hi Nikolay.
Thanks.
On Wed, 2018-02-21 at 08:34 +0200, Nikolay Borisov wrote:
> This looks like the one fixed by
> e8f1bc1493855e32b7a2a019decc3c353d94daf6 . It's tagged for stable so
> you
> should get it eventually.
Another consequence of this was that I couldn't sync/umount or shutdown
/Linux
>
>
> Feb 21 04:55:51 heisenberg kernel: BUG: unable to handle kernel paging
> request at 9fb75f827100
> Feb 21 04:55:51 heisenberg kernel: IP: btrfs_drop_inode+0x16/0x40 [btrfs]
This looks like the one fixed by
e8f1bc1493855e32b7a2a019decc3c353d94daf6 . It's tagged for stable
Hi.
Not sure if that's a bug in btrfs... maybe someone's interested in it.
Cheers,
Chris.
# uname -a
Linux heisenberg 4.14.0-3-amd64 #1 SMP Debian 4.14.17-1 (2018-02-14) x86_64
GNU/Linux
Feb 21 04:55:51 heisenberg kernel: BUG: unable to handle kernel paging request
at 9fb75f827100
Feb
10 matches
Mail list logo
