On Mon, 2016-12-26 at 00:12 +0000, Duncan wrote: > By themselves, free-space cache warnings are minor and not a serious > issue at all -- the cache is just that, a cache, designed to speed > operation but not actually necessary, and btrfs can detect and route > around space-cache corruption on-the-fly so by itself it's not a big > deal. Well... sure about that? Haven't we had recently that serious bug in the FST, which could cause data corruption as btrfs used space as free, while it wasn't?
> These warnings are however hints that something out of the routine > has > happened Which again just likely means that there was/is some bug in btrfs... other than that, why should it suddenly get some corrupted cache, when only ro-snapshots were removed in bewtween? > unless the filesystem itself, or a scrub, etc, has fixed things > in > the mean time. (And as I said, the space-cache is only a cache, > designed > to speed things up, cache corruption is fairly common and btrfs can > and > does deal with it without issue. When finishing the most recent backups, the fs in question got pretty fully and the error message I've spottet during btrfs check appeared in the kernel log as well: Dec 29 03:03:11 heisenberg kernel: BTRFS warning (device dm-1): block group 5431552376832 has wrong amount of free space Dec 29 03:03:11 heisenberg kernel: BTRFS warning (device dm-1): failed to load free space cache for block group 5431552376832, rebuilding it now (fs was NOT mounted with clear_cache) which implies it was now rebuilt However, after a subsquent fsck, the same error occurs there 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 7571911602176 bytes used err is 0 total csum bytes: 7381752972 total tree bytes: 11145035776 total fs tree bytes: 2100396032 total extent tree bytes: 1137082368 btree space waste bytes: 996179488 file data blocks allocated: 7560766566400 referenced 7681157672960 0 > 2) It recently came to the attention of the devs that the existing > btrfs > mount-option method of clearing the free-space cache only clears it > for > block-groups/chunks it encounters on-the-fly. It doesn't do a > systematic > beginning-to-end clear. So that calls for fixing the documentation as well?! > 3) As a result of #2, the devs only very recently added support in > btrfs > check for a /full/ space-cache-v1 clear, using the new > --clear-space-cache option. But your btrfs-progs v4.7.3 is too old > to > support it. I know it's in the v4.9 I just upgraded to... checking > the > wiki it appears the option was added in btrfs-progs v4.8.3 (v4.8.4 > for v2 > cache). And is the new option stable?! ;-) > Tho if you haven't recently run a scrub, I'd do that as well Well I did a full verification using my own checksum (i.e. every regular file in the fs has SHA512 sums attached as XATTR)... since that caused all data to be read, this should be identical to a scrub (at least as for the regular files data (no necessarily metadata), shouldn't it? Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
