Re: [PATCH v3 0/9] Btrfs: free space B-tree

[Omar Sandoval <osandov@osandov.com>]

On Mon, Sep 14, 2015 at 04:51:48PM +0200, Holger Hoffstätte wrote:
> On 09/14/15 08:04, Omar Sandoval wrote:
> > I went back and fixed the issues that came up since v2. Changes below. I
> > removed Josef's Reviewed-by on patch 9 because it was completely
> > rewritten to change the mount options like Dave suggested. These are
> > still based on 4.2
> 
> I decided to take one for the team and try this.
> 
> Merging it into my custom 4.1++ tree (with btrfs at ~4.3) worked flawlessly,
> just as the -progs bits. \o/
> 
> Upgrading existing filesystems works fine and performance on my peasant
> systems with SATA SSDs and rust is still good; not worse but also not
> noticeably better. Maybe it is and I just didn't notice; otherwise I guess
> that's good for a cache which is not really supposed to be noticeable. :)
> 
> Unmounting, remounting, btrfs check all also seem to work as expected.
> 
> Two questions:
> 
> 1) I believe the previous postings mentioned that the fst inherits the
> metadata properties - does this mean that e.g. on a single rotational
> disk with data=single,metadata=dup the fst is also dup? Is this good,
> bad, intentional? I guess it might prevent some of the problems with
> corrupted v1 caches that some people had.

Yeah, that's correct, the free space tree will have the same profile as
the rest of the metadata. There's certainly a cost in duplicating the
free space tree where the old space cache wouldn't have been duplicated,
but it's a good thing that the free space tree be consistent with the
rest of the metadata.

> 2) the following:
> 
> > - Changed the free_space_tree option to space_cache=v2 and made clear_cache
> >   clear the free space tree. If the free space tree has been created,
> >   the mount will fail unless space_cache=v2 or nospace_cache,clear_cache
> >   is given because we cannot allow the free space tree to get out of
> >   date.
> 
> also all seem to work in my testing (wrt. the clearing/downgrading to v1),
> but once a volume has been upgraded to v2 fst, a simple mount does not need
> to specify space_cache=v2 again; it seems to stick until cleared/downgraded.
> Not sure if that is what you meant to say.

Yeah, to be clear: if the filesystem is mounted with space_cache=v2
once, it's assumed from then on unless the user specifies otherwise
(i.e., nospace_cache,clear_cache). The idea there was to be consistent
with the original space_cache.

> Long story short: +1 excellent job and:
> Tested-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com>
> 
> cheers!
> 
> Holger

Thanks a ton for testing this out!

-- 
Omar