On Wed, Jul 01, 2015 at 07:32:08PM -0700, Darrick J. Wong wrote: > On Wed, Jul 01, 2015 at 11:58:43AM +1000, Dave Chinner wrote: > > On Thu, Jun 25, 2015 at 04:40:16PM -0700, Darrick J. Wong wrote: > > > Gate all the reflink functions (which generally involve an expensive > > > trip to the reflink btree) on an inode flag which is applied to both > > > inodes at reflink time. This minimizes reflink's impact on non-CoW > > > files. > > > > Ah, I see you do this reflink inode flag here. This should be one of > > the first patches, not the last. i.e. the patch series should > > build up all the supporting infrastructure in individual patches > > before adding any of the actual reflink implementation.... > > > > Also, the flag needs to go into the di_flags2 field, as the last > > flag in the di_flags field is reserved for a "more flags" flag if we > > ever need to add more flags to a v2 inode in a v4 filesystem... > > It looks to me like di_flags2 only exists in a v3 inode, and v3 inodes > only exist on v5 filesystems. I don't really mind using di_flags2 for > reflink (on the off chance you want to use bit 15 of di_flags for a > v2 inode) but I'm wondering how is it possible to have di_flags on a v4 fs? You mean how is it possible to have di_flags2 on a v4 fs? Internally when inodes are read off disk, they are converted to v3 format in memory. i.e. the struct xfs_icdinode is a v3 format structure. Hence when reading in v2 inodes, the di_flags2 field is present in the structure and it gets initialised to zero. When we format the in-memory inode to disk (in xfs_iflush_int()), we don't ever write the v3 fields back to the on disk inode structure, and hence the in-memory value of the di_flags2 field doesn't ever get written to disk. So while the various v3 inode fields are always present in the in-memory inode, if di_version = 2 then the v3 fields will be initialised to zero on read and will never be written back to disk... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
