On Wed, Jul 14, 2021 at 07:55:07PM +1000, Dave Chinner wrote: > > What about using a separate field for these? With this patch we've used > > up all 64-bits in the features field, which isn't exactly the definition > > of future proof.. > > I've used 16 mount option flags and 26 sb feature flags in this > patch set, so there's still 22 feature flags remaining before we > need to split them. This is all in-memory stuff so it's easy to > modify in future. Given that the flag sets are largely set in only > one place each and the check functions are all macro-ised, splitting > them when we do run out of bits is trivial. > > I'm more interested in trying to keep the cache footprint of > frequently accessed read-only data down to a minimum right now, > which is why I aggregated them in the first place... Oh, I missed the hole in the middle. Still not sure if mixing up mount and on-disk flags entirely is something I'm fully comfortable with. What do you think of at least marking the mount options in the name?
