Hey. Had the following on a Debian sid: Linux heisenberg 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux btrfs-progs v4.7.3 I was doing a btrfs check of a rather big btrfs (8TB device, nearly full), having many snapshots on it, all incrementally send from another 8TB device, which in turn functions as the master copy: # btrfs check /dev/mapper/data-a2 ; echo $? Checking filesystem on /dev/mapper/data-a2 UUID: f8acb432-7604-46ba-b3ad-0abe8e92c4db checking extents checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots checking csums checking root refs found 6805741969408 bytes used err is 0 total csum bytes: 6634558200 total tree bytes: 10292641792 total fs tree bytes: 2074869760 total extent tree bytes: 1100251136 btree space waste bytes: 885346193 file data blocks allocated: 6922343247872 referenced 7040929374208 0 => this already showed an unusual: cache and super generation don't match, space cache will be invalidated Where does it come from? Then I did some incremental send/receive (-p) from the other master 8TB master btrfs and another fsck afters wards: # btrfs check /dev/mapper/data-a2 ; echo $? Checking filesystem on /dev/mapper/data-a2 UUID: f8acb432-7604-46ba-b3ad-0abe8e92c4db checking extents checking free space cache checking fs roots checking csums checking root refs found 7467006156800 bytes used err is 0 total csum bytes: 7279407560 total tree bytes: 11069603840 total fs tree bytes: 2127314944 total extent tree bytes: 1141342208 btree space waste bytes: 922662895 file data blocks allocated: 7599280926720 referenced 7720960733184 0 => all fine... Afterwards I removed all ro-snapshots except the most recent one... and repeated the fsck: # btrfs check /dev/mapper/data-a2 ; echo $? Checking filesystem on /dev/mapper/data-a2 UUID: f8acb432-7604-46ba-b3ad-0abe8e92c4db checking extents checking free space cache block group 5431552376832 has wrong amount of free space failed to load free space cache for block group 5431552376832 checking fs roots checking csums checking root refs found 7427361222656 bytes used err is 0 total csum bytes: 7240763996 total tree bytes: 10998038528 total fs tree bytes: 2100297728 total extent tree bytes: 1137065984 btree space waste bytes: 992708933 file data blocks allocated: 7416363184128 referenced 7536754290688 0 => Isn't that some indication of a bug already? Nothing happened, just deletion of snapshots and there is apparently some free space cache corruption? Then I tried the usual recipe: mount /data/data-a/2/ -o clear_cache kernel said: Dec 25 22:14:17 heisenberg kernel: BTRFS info (device dm-2): force clearing of disk cache ...re-mounted,rw, deleted some regular files... repeated the fsck and again: # btrfs check /dev/mapper/data-a2 ; echo $? Checking filesystem on /dev/mapper/data-a2 UUID: f8acb432-7604-46ba-b3ad-0abe8e92c4db checking extents checking free space cache block group 5431552376832 has wrong amount of free space failed to load free space cache for block group 5431552376832 checking fs roots checking csums checking root refs found 7427284213760 bytes used err is 0 total csum bytes: 7240689688 total tree bytes: 10997907456 total fs tree bytes: 2100281344 total extent tree bytes: 1137049600 btree space waste bytes: 992679805 file data blocks allocated: 7416286306304 referenced 7536677412864 0 => same error again... Any ideas how to resolve? And is this some serious error that could have caused corruptions? Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
