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.
