Re: [GIT PULL] xfs: new code for 6.7

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Nov 09, 2023 at 03:46:14PM +0100, Christoph Hellwig wrote:
> On Wed, Nov 08, 2023 at 11:39:45PM -0800, Darrick J. Wong wrote:
> > Dave and I started looking at this too, and came up with: For rtgroups
> > filesystems, what if rtpick simply rotored the rtgroups?  And what if we
> > didn't bother persisting the rotor value, which would make this casting
> > nightmare go away in the long run.  It's not like we persist the agi
> > rotors.
> 
> Yep.  We should still fix the cast and replace it with a proper union
> or other means for pre-RTG file systems given that they will be around
> for while.

<nod> Linus' fixup stuffs the seq value in tv_sec.  That's not great
since the inode writeout code then truncates the upper 32 bits, but
that's what the kernel has been doing for 5+ years now.

Dave suggested that we might restore the pre-4.6 behavior by explicitly
encoding what we used to do:

	inode->i_atime.tv_sec = seq & 0xFFFFFFFF;
	inode->i_atime.tv_nsec = seq >> 32;

(There's a helper in 6.7 for this, apparently.)

But then I pointed out that the entire rtpick sequence counter thing
merely provides a *starting point* for rtbitmap searches.  So it's not
like garbled values result in metadata inconsistency.  IOWs, it's
apparently benign.

IOWs, how much does anyone care about improving on Linus' fixup?

--D