Re: [PATCH] btrfs: avoid transaction commit on any fsync after subvolume creation

[Josef Bacik <josef@toxicpanda.com>]

On Tue, Jun 11, 2024 at 12:10:24PM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> As of commit 1b53e51a4a8f ("btrfs: don't commit transaction for every
> subvol create") we started to make any fsync after creating a subvolume
> to fallback to a transaction commit if the fsync is performed in the
> same transaction that was used to create the subvolume. This happens
> with the following at ioctl.c:create_subvol():
> 
>   $ cat fs/btrfs/ioctl.c
>   (...)
>       /* Tree log can't currently deal with an inode which is a new root. */
>       btrfs_set_log_full_commit(trans);
>   (...)
> 
> Note that the comment is misleading as the problem is not that fsync can
> not deal with the root inode of a new root, but that we can not log any
> inode that belongs to a root that was not yet persisted because that would
> make log replay fail since the root doesn't exist at log replay time.
> 
> The above simply makes any fsync fallback to a full transaction commit if
> it happens in the same transaction used to create the subvolume - even if
> it's an inode that belongs to any other subvolume. This is a brute force
> solution and it doesn't necessarily improve performance for every workload
> out there - it just moves a full transaction commit from one place, the
> subvolume creation, to another - an fsync for any inode.
> 
> Just improve on this by making the fallback to a transacton commit only
> for an fsync against an inode of the new subvolume, or for the directory
> that contains the dentry that points to the new subvolume (in case anyone
> attempts to fsync the directory in the same transaction).
> 
> Signed-off-by: Filipe Manana <fdmanana@suse.com>

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks,

Josef