On 2016-05-16 02:20, Qu Wenruo wrote:
Duncan wrote on 2016/05/16 05:59 +0000:
Qu Wenruo posted on Mon, 16 May 2016 10:24:23 +0800 as excerpted:
IIRC clear_cache option is fs level option.
So the first mount with clear_cache, then all subvolume will have
clear_cache.
Question: Does clear_cache work with a read-only mount?
Good question.
But easy to check.
I just checked it and found even that's possible, it doesn't work.
Free space cache inode bytenr doesn't change and no generation change.
While without ro, it did rebuild free space cache for *SOME* chunks, not
*ALL* chunks.
And that's the problem I'm just chasing today.
Short conclude: clear_cache mount option will only rebuild free space
cache for chunks which we allocated space from, during the mount time of
clear_cache.
(Maybe I'm just out-of-date and some other devs may already know that)
And kernel fix for that is a little tricky, as we don't really read out
all free space cache, but only when we are going to allocate space from
them.
For any free space cache we didn't read out, they won't be rebuilt.
You can find my reproducer in my just submitted
patch(https://patchwork.kernel.org/patch/9098431/).
That behavior makes things a little confusing, which users may continue
hitting annoying free space cache warning from kernel, even they try to
use clear_cache mount option.
Anyway, I'll add ability for manually wipe out all/given free space
cache to btrfsck, at least creating a solution to really rebuild all v1
free space cache.
FWIW, I think it's possible to do this by mounting with clear_cache and
then running a full balance on the filesystem. Having an option to do
this on an unmounted FS would be preferred of course, as that would
almost certainly be more efficient on any reasonably sized filesystem.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
