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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux