progs: differing "found N bytes used" for original/lowmem mode

progs: differing "found N bytes used" for original/lowmem mode

[Christoph Anton Mitterer]

Hey.

This is with kernel 6.0.5 and progs 6.0.

When btrfs-checking the same fs (without it being mounted in between)
with --mode=original and lowmem, I get differing values for the "found
N bytes used, no error found" line.

The fs in question was created with the same kernel/progs and filled
with some 600GB.


I vaguely remember that this used to be the case in the past but was
resolved eventually as a bug(?).


# btrfs check --mode lowmem /dev/mapper/newfujitsu ; echo $?
Opening filesystem to check...
Checking filesystem on /dev/mapper/newfujitsu
UUID: 3c1b32b6-5940-11ed-b447-53dfc28b8b9e
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs done with fs roots in lowmem mode, skipping
[7/7] checking quota groups skipped (not enabled on this FS)
found 581442859008 bytes used, no error found
total csum bytes: 566096284
total tree bytes: 1760264192
total fs tree bytes: 1012596736
total extent tree bytes: 71417856
btree space waste bytes: 253635124
file data blocks allocated: 629161189376
 referenced 600678027264
0

# btrfs check /dev/mapper/newfujitsu ; echo $?
Opening filesystem to check...
Checking filesystem on /dev/mapper/newfujitsu
UUID: 3c1b32b6-5940-11ed-b447-53dfc28b8b9e
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[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)
found 581442187264 bytes used, no error found
total csum bytes: 566096284
total tree bytes: 1760264192
total fs tree bytes: 1012596736
total extent tree bytes: 71417856
btree space waste bytes: 253635124
file data blocks allocated: 629161189376
 referenced 600678027264
0


Just in case someone is interested in having a look at this.

Thanks,
Chris.