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.