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.