Re: [PATCH] btrfs: don't commit transaction for every subvol create

[David Sterba <dsterba@suse.cz>]

On Tue, Apr 11, 2023 at 03:10:53PM -0400, Sweet Tea Dorminy wrote:
> Recently a Meta-internal workload encountered subvolume creation taking
> up to 2s each, significantly slower than directory creation. As they
> were hoping to be able to use subvolumes instead of directories, and
> were looking to create hundreds, this was a significant issue. After
> Josef investigated, it turned out to be due to the transaction commit
> currently performed at the end of subvolume creation.
> 
> This change improves the workload by not doing transaction commit for every
> subvolume creation, and merely requiring a transaction commit on fsync.
> In the worst case, of doing a subvolume create and fsync in a loop, this
> should require an equal amount of time to the current scheme; and in the
> best case, the internal workload creating hundreds of subvols before
> fsyncing is greatly improved.
> 
> While it would be nice to be able to use the log tree and use the normal
> fsync path, logtree replay can't deal with new subvolume inodes
> presently.
> 
> It's possible that there's some reason that the transaction commit is
> necessary for correctness during subvolume creation; however,
> git logs indicate that the commit dates back to the beginning of
> subvolume creation, and there are no notes on why it would be necessary.
> 
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

For subvolume creation the situation is much easier than with deletion,
as said by others, the semantics is similar to creating a directory,
fsync works to make sure the data are persistent.

So I think it's safe and allows the use case of creating many subvolumes
without the full transaction commit overhead. And we don't need the
commandline options. Added to misc-next, thanks.