On Tue, Apr 07, 2020 at 11:20:00AM +1000, Dave Chinner wrote: > Ok, I think you've limited what we can do here by using this "fill > holes" variable split. I've never liked doing this, and we've only > done it in the past when we haven't had space in the inode to create > a new 32 bit variable. > > IOWs, this is a v5 format feature only, so we should just create a > new variable: > > __be32 di_attr_nextents; > > With that in place, we can now do what we did extending the v1 inode > link count (16 bits) to the v2 inode link count (32 bits). > > That is, when the attribute count is going to overflow, we set a > inode flag on disk to indicate that it now has a 32 bit extent count > and uses that field in the inode, and we set a RO-compat feature > flag in the superblock to indicate that there are 32 bit attr fork > extent counts in use. > > Old kernels can still read the filesystem, but see the extent count > as "max" (65535) but can't modify the attr fork and hence corrupt > the 32 bit count it knows nothing about. > > If the kernel sees the RO feature bit set, it can set the inode flag > on inodes it is modifying and update both the old and new counters > appropriately when flushing the inode to disk (i.e. transparent > conversion). > > In future, mkfs can then set the RO feature flag by default so all > new filesystems use the 32 bit counter. I don't like just moving to a new counter. This wastes precious space that is going to be really confusing to reuse later, and doesn't really help with performance. And we can do the RO_COMPAT trick even without that.
