On Wed, Aug 17, 2022 at 08:10:22AM -0400, Jeff Layton wrote: > On Wed, 2022-08-17 at 09:37 +1000, Dave Chinner wrote: > > On Tue, Aug 16, 2022 at 01:14:55PM -0400, David Wysochanski wrote: > > > On Tue, Aug 16, 2022 at 9:19 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > I have a test (details below) that shows an open issue with NFSv4.x + > > > fscache where an xfs exported filesystem would trigger unnecessary > > > over the wire READs after a umount/mount cycle of the NFS mount. I > > > previously tracked this down to atime updates, but never followed > > > through on any patch. Now that Jeff worked it out and this patch is > > > under review, I built 5.19 vanilla, retested, then built 5.19 + this > > > patch and verified the problem is fixed. > > > > And so the question that needs to be answered is "why isn't relatime > > working for this workload to avoid unnecessary atime updates"? > > > > Which then makes me ask "what's changing atime on the server between > > client side reads"? > > > > Which then makes me wonder "what's actually changing iversion on the > > server?" because I don't think atime is the issue here. > > > > I suspect that Jeff's patch is affecting this test case by removing > > iversion updates when the data is written back on the server. i.e. > > delayed allocation and unwritten extent conversion will no longer > > bump iversion when they log the inode metadata changes associated > > with extent allocation to store the data being written. There may > > be other places where Jeff's patch removes implicit iversion > > updates, too, so it may not be writeback that is the issue here. > > > > How that impacts on the observed behaviour is dependent on things I > > don't know, like what cachefiles is doing in the background, > > especially across NFS client unmount/mount cycles. However, this all > > makes me think the "atime is updated" behaviour is an observed > > symptom of something else changing iversion and/or cmtime between > > reads from the server... > > > > You may be right here. > > What I see with both noatime and relatime is that the first read after a > write to a file results in the i_version being incremented, but then it > doesn't change on subsequent reads. Write to the file again, and the > i_version will get incremented again on the next read and then not again > until there is a write. Yup, that is exactly the behaviour relatime encodes at the VFS. THe data write updates mtime (or is it ctime? doesn't matter, though) and the very next atime access check done by the VFS sees that the mtime is more recent than the atime, so it asks the filesystem to do an atime update. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
