On 2019/12/30 下午1:50, Patrick Erley wrote: > On Sun, Dec 29, 2019 at 9:47 PM Patrick Erley <pat-lkml@xxxxxxxxx> wrote: >> >> On Sun, Dec 29, 2019 at 9:43 PM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >>> >>> >>> >>> On 2019/12/30 下午1:36, Patrick Erley wrote: >>>> (ugh, just realized gmail does top replies. Sorry... will try to >>>> figure out how to make gsuite behave like a sane mail client before my >>>> next reply): >>>> >>>> here's btrfs check /dev/nvme0n1p2 (sda3, which is a mirror of it, has >>>> exactly the same output) >>>> >>>> [1/7] checking root items >>>> [2/7] checking extents >>>> [3/7] checking free space cache >>>> [4/7] checking fs roots >>>> [5/7] checking only csums items (without verifying data) >>>> [6/7] checking root refs >>>> [7/7] checking quota groups skipped (not enabled on this FS) >>>> Opening filesystem to check... >>>> Checking filesystem on /dev/nvme0n1p2 >>>> UUID: 815266d6-a8b9-4f63-a593-02fde178263f >>>> found 89383137280 bytes used, no error found >>>> total csum bytes: 85617340 >>>> total tree bytes: 1670774784 >>>> total fs tree bytes: 1451180032 >>>> total extent tree bytes: 107905024 >>>> btree space waste bytes: 413362851 >>>> file data blocks allocated: 90769887232 >>>> referenced 88836960256 >>> >>> It looks too good to be true, is the btrfs-progs v5.4? IIRC in v5.4 we >>> should report inodes generation problems. >> >> Hurray Bottom Reply? >> >> /usr/src/initramfs/bin $ ./btrfs.static --version >> btrfs-progs v5.4 This is strange. 6084adam|thinkpad|~$ btrfs check --mode=lowmem test.img Opening filesystem to check... Checking filesystem on test.img UUID: c6c6ddd2-01c1-47fc-b699-cacfae9d4bfd [1/7] checking root items [2/7] checking extents [3/7] checking free space cache cache and super generation don't match, space cache will be invalidated [4/7] checking fs roots ERROR: invalid inode generation for ino 257, have 8858344568388091671 expect [0, 9) ERROR: errors found in fs roots found 131072 bytes used, error(s) found total csum bytes: 0 total tree bytes: 131072 total fs tree bytes: 32768 total extent tree bytes: 16384 btree space waste bytes: 123409 file data blocks allocated: 0 referenced 0 6085adam|thinkpad|~$ btrfs --version btrfs-progs v5.4 As expected, v5.4 should detect such problem without problem. Would you please provide extra tree dump to help us to determine what makes btrfs check unable to detect such problems? # btrfs ins dump-tree -b 303629811712 /dev/dm-1 > > Dumb question, did I need to do that while booting a post 5.1 kernel? > I ran these while not having the filesystem mounted, but against > kernel 5.1. I can easily repeat against 5.4. Kernel version doesn't affect at all. All the detection and repair should be able to be done by btrfs-progs. But it would be better to use v5.4 to quick verify the fix is working. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
