Re: Do btrfs compression option changes need to be atomic?

[David Sterba <dsterba@suse.cz>]

On Tue, Aug 21, 2018 at 02:46:30PM +0100, David Howells wrote:
> Should changes to the compression options on a btrfs mount be atomic, the
> problem being that they're split across three variables?

Do you mean the compression type (btrfs_fs_info::compress_type) and the
related bits in btrfs_fs_info::mount_opt ? There are more compression
types but not used in the mount context.  I assume you're interested
only in the mount-time settings, otherwise the defrag and per-inode
compression has higher priority over the global settings.

When an extent is going to be compressed, the current value of
compression type is read and then passed around.

> Further to that, how much of an issue is it if the configuration is split out
> into its own struct that is accessed from struct btrfs_fs_info using RCU?

Depends on how intrusive it's going to be, the mount opions are tested
at many places. The RCU overhead and "locking" is lightweight enough so
it should not be a problem in principle, but without seeing the code I
can't tell.