From: Gard Vaaler <gardv@megacandy.net>
To: unlisted-recipients:; (no To-header on input)
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Unrecoverable corruption after loss of cache
Date: Wed, 4 Dec 2019 21:21:40 +0100 [thread overview]
Message-ID: <C9B1933C-7F87-40D2-82F2-9D668450C01A@megacandy.net> (raw)
In-Reply-To: <CAJCQCtRA2+X-ke4yJ4H8o49ZA9mSOFabLpNeXd=4ULDg99rFgQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
> 4. des. 2019 kl. 20:08 skrev Chris Murphy <lists@colorremedies.com>:
> Why do you think it's complaining about the journal? I'm not seeing
> tree log related messages here.
Thanks for the reply! That must be a misunderstanding on my part (it's called "transid", which suggested something in the journal to me).
> Is the output provided complete or are
> there additional messages?
No, that's it.
> What do you get for:
>
> btrfs insp dump-s /dev/X
Attached.
[-- Attachment #2: btrfs-insp-dump --]
[-- Type: application/octet-stream, Size: 2682 bytes --]
[liveuser@localhost-live btrfs-progs-5.4]$ sudo ./btrfs insp dump-s /dev/bcache0superblock: bytenr=65536, device=/dev/bcache0
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0xdaa8bba5 [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 8c4a9e0d-bfe9-4b8f-be8f-1899c58b00b3
metadata_uuid 8c4a9e0d-bfe9-4b8f-be8f-1899c58b00b3
label
generation 319148
root 2529691058176
sys_array_size 129
chunk_root_generation 298799
root_level 1
chunk_root 2534052790272
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 6000110088192
bytes_used 3739095216128
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 2
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x161
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 319148
uuid_tree_generation 13
dev_item.uuid 7215ede5-5997-47c2-96e3-4b43f67f1eb6
dev_item.fsid 8c4a9e0d-bfe9-4b8f-be8f-1899c58b00b3 [match]
dev_item.type 0
dev_item.total_bytes 2000398925824
dev_item.bytes_used 1515066556416
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 2
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
[liveuser@localhost-live btrfs-progs-5.4]$ sudo ./btrfs insp dump-s /dev/bcache1
superblock: bytenr=65536, device=/dev/bcache1
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0xf1f043cd [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 8c4a9e0d-bfe9-4b8f-be8f-1899c58b00b3
metadata_uuid 8c4a9e0d-bfe9-4b8f-be8f-1899c58b00b3
label
generation 319148
root 2529691058176
sys_array_size 129
chunk_root_generation 298799
root_level 1
chunk_root 2534052790272
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 6000110088192
bytes_used 3739095216128
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 2
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x161
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 319148
uuid_tree_generation 13
dev_item.uuid 6f60e735-3829-4223-aa13-dbb377fa28ff
dev_item.fsid 8c4a9e0d-bfe9-4b8f-be8f-1899c58b00b3 [match]
dev_item.type 0
dev_item.total_bytes 3999711162368
dev_item.bytes_used 3407004565504
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
[-- Attachment #3: Type: text/plain, Size: 317 bytes --]
> What kernel version was being used at the time of the first problem instance?
Fedora's 5.2.8-300 kernel.
> The transid messages above suggest some kind of failure to actually
> commit what should have ended up on stable media. Also please provide:
>
> btrfs-find-root /dev/
Attached (compressed).
[-- Attachment #4: btrfs-find-root.xz --]
[-- Type: application/octet-stream, Size: 8096 bytes --]
[-- Attachment #5: Type: text/plain, Size: 47 bytes --]
> btrfs check --mode=lowmem /dev/
Attached.
[-- Attachment #6: btrfs-check --]
[-- Type: application/octet-stream, Size: 1086 bytes --]
[liveuser@localhost-live btrfs-progs-5.4]c$ sudo ./btrfs check --mode=lowmem /dev/bcache0
Opening filesystem to check...
parent transid verify failed on 2529691090944 wanted 319147 found 314912
parent transid verify failed on 2529691090944 wanted 319147 found 310171
parent transid verify failed on 2529691090944 wanted 319147 found 314912
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=2529690976256 item=0 parent level=2 child level=0
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system
[liveuser@localhost-live btrfs-progs-5.4]$ sudo ./btrfs check --mode=lowmem /dev/bcache1
Opening filesystem to check...
parent transid verify failed on 2529691090944 wanted 319147 found 314912
parent transid verify failed on 2529691090944 wanted 319147 found 310171
parent transid verify failed on 2529691090944 wanted 319147 found 314912
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=2529690976256 item=0 parent level=2 child level=0
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system
[-- Attachment #7: Type: text/plain, Size: 568 bytes --]
> The latter will take a while and since it is an offline check will
> need to be done in initramfs, or better from Live media which will
> make it easier to capture the output. I recommend btrfs-progs not
> older than 5.1.1 if possible. It is only for check, not with --repair,
> so the version matters somewhat less if it's not too old.
As you can see, it terminates almost immediately with an IO error. However, there's no error in the dmesg on the underlying device, which makes me think there's a bad bounds check or something similar.
--
Gard
next prev parent reply other threads:[~2019-12-04 20:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-01 17:27 Unrecoverable corruption after loss of cache Gard Vaaler
2019-12-01 18:51 ` Nikolay Borisov
2019-12-02 21:27 ` Gard Vaaler
2019-12-05 2:45 ` Zygo Blaxell
2019-12-04 15:50 ` Gard Vaaler
2019-12-04 19:08 ` Chris Murphy
2019-12-04 20:21 ` Gard Vaaler [this message]
[not found] ` <B154F1B0-C80A-4E7E-B105-B0E654279E28@megacandy.net>
2019-12-04 21:09 ` Chris Murphy
2019-12-05 0:34 ` Gard Vaaler
2019-12-05 1:26 ` Chris Murphy
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=C9B1933C-7F87-40D2-82F2-9D668450C01A@megacandy.net \
--to=gardv@megacandy.net \
--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).