search

kdave / btrfs-progs

Development of userspace BTRFS tools
GNU General Public License v2.0
527 stars 239 forks source link

recurring "cache and super generation don't match, space cache will be invalidated" #821

Closed tribbloid closed 1 week ago

tribbloid commented 1 week ago 
liveuser@localhost-live:~$ sudo btrfs check --repair /dev/disk/by-label/Home
enabling repair mode
WARNING:

    Do not use --repair unless you are advised to do so by a developer
    or an experienced user, and then only after having accepted that no
    fsck can successfully repair all types of filesystem corruption. E.g.
    some software or hardware bugs can fatally damage a volume.
    The operation will start in 10 seconds.
    Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
Checking filesystem on /dev/disk/by-label/Home
UUID: a5c81116-78a5-4edb-b57c-b08e90e1391b
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
checksum verify failed on 58720256 wanted 0x3caae502 found 0x99f99bda
No device size related problem found
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
[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 421089386496 bytes used, no error found
total csum bytes: 19137532
total tree bytes: 2635005952
total fs tree bytes: 2351742976
total extent tree bytes: 256081920
btree space waste bytes: 576841045
file data blocks allocated: 486477520896
 referenced 426042204160

after rebooting:

liveuser@localhost-live:~$ sudo btrfs check --repair /dev/disk/by-label/Home
enabling repair mode
WARNING:

    Do not use --repair unless you are advised to do so by a developer
    or an experienced user, and then only after having accepted that no
    fsck can successfully repair all types of filesystem corruption. E.g.
    some software or hardware bugs can fatally damage a volume.
    The operation will start in 10 seconds.
    Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
Checking filesystem on /dev/disk/by-label/Home
UUID: a5c81116-78a5-4edb-b57c-b08e90e1391b
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
checksum verify failed on 58720256 wanted 0x3caae502 found 0x99f99bda
No device size related problem found
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
[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 421089386496 bytes used, no error found
total csum bytes: 19137532
total tree bytes: 2635005952
total fs tree bytes: 2351742976
total extent tree bytes: 256081920
btree space waste bytes: 576841045
file data blocks allocated: 486477520896
 referenced 426042204160
tribbloid commented 1 week ago

kernel 6.8, version 6.8, fedora 40 live

tribbloid commented 1 week ago

also observed on nixOS 24.05 , version 6.9

adam900710 commented 1 week ago

That's totally fine, kernel would detect and rebuild the cache if needed, that's why it's not counted as error.

If it really bothers you, just go v2 cache.

tribbloid commented 1 week ago

that's why I rebooted my computer, it wasn't rebuild even with 6.9 kernel (fairly up-to-date).

I guess things related to kernel shouldn't be reported here

adam900710 commented 1 week ago

No, I have already explained that, the cache will only be rebuild if the offending cache is modified.

Thus a simple reboot won't help.

It's really recommended to go v2 cache, since we do not even do much test coverage for the old v1 cache anymore.