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
