Christoph Anton Mitterer posted on Sun, 25 Dec 2016 23:00:34 +0100 as excerpted: > # btrfs check /dev/mapper/data-a2 ; echo $? > Checking filesystem on /dev/mapper/data-a2 [...] > checking free space cache > block group 5431552376832 has wrong amount of free space > failed to load free space cache for block group 5431552376832 [...] > 0 > > => same error again... > > Any ideas how to resolve? And is this some serious error that could have > caused corruptions? 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. These warnings are however hints that something out of the routine has happened, and that you might wish to freshen your backups, run btrfs check and scrub and see if anything else is wrong (if you get them at mount, you got them /running/ btrfs check and nothing else out of the ordinary was reported), etc. Three things to note: 1) Plain btrfs check, without options that trigger fixes, is read-only, so you are likely to see anything unusual it reports again in repeated runs, 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. In fact btrfs has the nospace_cache option to entirely disable it at mount.) 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. As such, in some instances it's possible to run with the clear_cache mount option (see the btrfs (5) manpage for mount option specifics, but to head off another question, it's recommended to stay with v1 cache for now) and still see space-cache warnings you thought should be cleared up, if btrfs didn't deal with those chunks in the run where the cache was cleared. 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). So if you want you can try the clear_cache mount option, and if that doesn't do it, upgrade to a current btrfs-progs and run it with the --clear-space-cache option, but you're not endangering your filesystem or anything by simply waiting until you get a btrfs-progs update from your distro, if you decide to. The space-cache warnings aren't indicative of a serious problem now and btrfs deals with them on its own, they are simply hints that something, perhaps a crash with the btrfs mounted writable, happened at some time in the past, and that it it might be wise to investigate further for other damage, which you've already done, so you're good. =:^) Tho if you haven't recently run a scrub, I'd do that as well (and in fact recommend running it before check if you can successfully mount), since the problems it detects and fixes are conceptually different than the ones btrfs check deals with. Scrub deals with actual on-media corruption, blocks not matching their checksum, while check deals with filesystem logic errors, whether or not the blocks containing them match the checksum. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
