Thread (15 messages) 15 messages, 3 authors, 2021-07-25

Re: bad file extent, some csum missing - how to check that restored volumes are error-free?

From: Qu Wenruo <hidden>
Date: 2021-07-15 22:31:05


On 2021/7/16 上午6:19, Dave T wrote:
quoted
quoted
quoted
quoted
You may want to run "btrfs check --mode=lowmem" to get a more human
readable report.
   From that we can get a full view of the problem and give better advice.
Thank you. I will try to do that after I finish fully setting up the new SSD.
Looking forward to the output.
kernel version 5.12.15-arch1-1 (linux@archlinux)

# btrfs scrub start -B /
scrub done for ff2b04eb-088c-4fb0-9ad4-84780d23f821
Scrub started:    Thu Jul 15 11:44:47 2021
Status:           finished
Duration:         0:15:53
Total to scrub:   310.04GiB
Rate:             327.54MiB/s
Error summary:    no errors found

# btrfs check --mode=lowmem /dev/mapper/xyz
Opening filesystem to check...
Checking filesystem on /dev/mapper/extluks
UUID: ff2b04eb-088c-4fb0-9ad4-84780d23f821
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
ERROR: root 329 EXTENT_DATA[262 536576] compressed extent must have
csum, but only 0 bytes have, expect 65536
ERROR: root 329 EXTENT_DATA[262 536576] is compressed, but inode flag
doesn't allow it
ERROR: root 329 EXTENT_DATA[7070 0] compressed extent must have csum,
but only 0 bytes have, expect 4096
ERROR: root 329 EXTENT_DATA[7070 0] is compressed, but inode flag
doesn't allow it
ERROR: root 329 EXTENT_DATA[7242 0] compressed extent must have csum,
but only 0 bytes have, expect 28672
ERROR: root 329 EXTENT_DATA[7242 0] is compressed, but inode flag
doesn't allow it
ERROR: root 329 EXTENT_DATA[7246 0] compressed extent must have csum,
but only 0 bytes have, expect 16384
ERROR: root 329 EXTENT_DATA[7246 0] is compressed, but inode flag
doesn't allow it
ERROR: root 329 EXTENT_DATA[7252 0] compressed extent must have csum,
but only 0 bytes have, expect 32768
ERROR: root 329 EXTENT_DATA[7252 0] is compressed, but inode flag
doesn't allow it
ERROR: root 329 EXTENT_DATA[7401 0] compressed extent must have csum,
but only 0 bytes have, expect 12288
ERROR: root 329 EXTENT_DATA[7401 0] is compressed, but inode flag
doesn't allow it
OK, lowmem mode indeed did a much better job.

This is a very strange bug.

This means:

- The compressed extent doesn't have csum
   Which shouldn't be possible for recent kernels.

- The compressed extent exists for inode which has NODATASUM flag
   Not possible again for recent kernels.

But IIRC there are old kernels allowing such compression + nodatasum.

I guess that's the reason why you got EIO when reading it.

When we failed to find csum, we just put 0x00 as csum, and then when you 
read the data, it's definitely going to cause csum mismatch and nothing 
get read out.

This can be worked around by recent "rescue=idatacsums" mount option.

But to me, this really looks like some old fs, with some inodes created 
by older kernels.
and hundreds more errors of this same type... (I guess you don't want
to see every error line.)

ERROR: root 334 EXTENT_DATA[184874 0] compressed extent must have
csum, but only 0 bytes have, expect 16384
ERROR: root 334 EXTENT_DATA[184874 0] is compressed, but inode flag
doesn't allow it
ERROR: errors found in fs roots
found 327307210752 bytes used, error(s) found
total csum bytes: 282325056
total tree bytes: 5130452992
total fs tree bytes: 4535648256
total extent tree bytes: 249790464
btree space waste bytes: 848096029
file data blocks allocated: 588119937024
  referenced 568343642112

I'm interested in your thoughts about what might have caused this, and
how I should repair / fix it. Are any of these options appropriate?

-  btrfs rescue chunk-recover /dev/mapper/xyz
Definite no.

Any rescue command should only be used when some developer suggested.
-  btrfs check --repair --init-extent-tree /dev/mapper/zyz
No again, this is even more dangerous.
- btrfs check --repair --init-csum-tree /dev/mapper/xyz
This may solve the read error, but we will still report the NODATACSUM 
problem for the compressed extent.

Have you tried to remove the NODATASUM option for those involved inodes?

If it's possible to remove NODATASUM for those inodes, then 
--init-csum-tree should be able to solve the problem.

Thanks,
Qu
Thank you.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help