David Sterba <dste...@suse.cz> wrote:

> The ordering of the bits set/cleared can prevent unwanted combinations,
> like: when the COMPRESS bit is set, there's no NODATACOW anymore:
> 
> - clear NODATACOW
> - set compress_type
> - set COMPRESS
> 
> I haven't checked with the sources if this is so.

The current code doesn't use memory barriers or atomic ops, so you must assume
that those memory operations can be reordered/merged by the compiler or the
cpu.

> So the changes would be possible in one atomic (bitwise) call? Instead
> of:
> 
>   clear_bit(opts, NODATACOW)
>   set_bit(opts, COMPRESS)
> 
> do:
> 
>   set_bits_with_mask(opts, COMPRESS, BTRFS_DATA__STORAGE_OPT)

After the mount API changes, the value for the variable will be composed in a
separate context and then applied with a single assignment after printing any
messages about changes in active options.

> Side note: up to now we're all used to the NO* naming and semantics of
> the feature bits, so it might take some time to do the mental switch.

Yeah - I've actually switched them all to positive naming in what I have so
far as it simplifies the code and makes it easier to think about (for me at
least).

David

Reply via email to