On 2019/12/28 下午5:49, Michael Ruiz wrote: >> There are quite some reports about this problem. So far no real >> corrupted confirmed. >> >> You can confirm it by scrub. >> >> I'm afraid there is some bug in data balance code which leads to this. >> We will dig further to pin down the cause. >> >> BTW, does that problem always show up at block group 253562454016? Or it >> randomly shows up at different block groups? >> >> Thanks, >> Qu > > Hi Qu, > It appears to be the same data blocks giving me this issue. I have tried it > while mounting from a bootable usb and in my arch linux install both with > similar results. So it looks like you will hit the same -EIO even just relocating that specific block group using vrange filter. > I should also mention I have a btrfs root partition within a > luks lvm partition becuase btrfs provides no encryption. I'm not sure this > makes a difference. I don't believe it would cause any difference. > Would you suggest running somekind of disk check or by > running scrub? Please let me know what I should try to resolve this. Running a scrub is always preferred. An `btrfs check` run would be even better. If all above reports no error, we need more info to dig. (See below). > 谢谢 > > ``` BEGIN DEBUG INFO ``` > ERROR: error during balancing '/': Input/output error > [ 465.880807] BTRFS info (device dm-1): found 25 extents > [ 470.501319] BTRFS info (device dm-1): found 25 extents > [ 471.713073] BTRFS info (device dm-1): relocating block group 253562454016 > flags data > [ 472.251356] BTRFS warning (device dm-1): csum failed root -9 ino 262 off > 1048576 csum 0x9a7afaa8 expected csum 0x63e15594 mirror 1 Another question, is the reported csum (both have and expected) always the same? > [ 472.254390] BTRFS warning (device dm-1): csum failed root -9 ino 262 off > 1048576 csum 0x9a7afaa8 expected csum 0x63e15594 mirror 1 This line means two things: - We have extra inodes in data reloc tree Normally data reloc only has one inode, 256. It's possible we have some extra orphan inodes. Would you like to do the following dump? # btrfs ins dump-tree -t data_reloc /dev/dm-1 Although the result is not something representing the content when we hit the bug, it may still provide some clue. - The original data is from logical 253563502592 Would you like to check which file(s) owns that logical? It can be done by the following command: # btrfs ins logical-resolve 253563502592 <mnt> Unlike previous command, it needs to be executed on a mounted btrfs other than the block device. And the info about that inode is also helpful, like its attr (nodatacow?). Thanks, Qu > ``` END DEBUG INFO ``` >
Attachment:
signature.asc
Description: OpenPGP digital signature
