On Tue, Apr 11, 2023 at 5:38 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > (Apologies for the resend, but I didn't send this with a wide enough > distribution list originally). > > A few weeks ago, during one of the discussions around i_version, Dave > Chinner wrote this: > > "You've missed the part where I suggested lifting the "nfsd sampled > i_version" state into an inode state flag rather than hiding it in > the i_version field. At that point, we could optimise away the > secondary ctime updates just like you are proposing we do with the > i_version updates. Further, we could also use that state it to > decide whether we need to use high resolution timestamps when > recording ctime updates - if the nfsd has not sampled the > ctime/i_version, we don't need high res timestamps to be recorded > for ctime...." > > While I don't think we can practically optimize away ctime updates > like we do with i_version, I do like the idea of using this scheme to > indicate when we need to use a high-res timestamp. > > This patchset is a first stab at a scheme to do this. It declares a new > i_state flag for this purpose and adds two new vfs-layer functions to > implement conditional high-res timestamp fetching. It then converts both > tmpfs and xfs to use it. > > This seems to behave fine under xfstests, but I haven't yet done > any performance testing with it. I wouldn't expect it to create huge > regressions though since we're only grabbing high res timestamps after > each query. > > I like this scheme because we can potentially convert any filesystem to > use it. No special storage requirements like with i_version field. I > think it'd potentially improve NFS cache coherency with a whole swath of > exportable filesystems, and helps out NFSv3 too. > > This is really just a proof-of-concept. There are a number of things we > could change: > > 1/ We could use the top bit in the tv_sec field as the flag. That'd give > us different flags for ctime and mtime. We also wouldn't need to use > a spinlock. > > 2/ We could probably optimize away the high-res timestamp fetch in more > cases. Basically, always do a coarse-grained ts fetch and only fetch > the high-res ts when the QUERIED flag is set and the existing time > hasn't changed. > > If this approach looks reasonable, I'll plan to start working on > converting more filesystems. > > One thing I'm not clear on is how widely available high res timestamps > are. Is this something we need to gate on particular CONFIG_* options? > > Thoughts? Jeff, Considering that this proposal is pretty uncontroversial, do you still want to discuss/lead a session on i_version changes in LSF/MM? I noticed that Chuck listed "timespamt resolution and i_version" as part of his NFSD BoF topic proposal [1], but I do not think all of these topics can fit in one 30 minute session. Dave, I would like to use this opportunity to invite you and any developers that are involved in fs development and not going to attend LSF/MM in-person, to join LSF/MM virtually for some sessions that you may be interested in. See this lore query [2] for TOPICs proposed this year. You can let me know privately which sessions you are interested in attending and your time zone and I will do my best to schedule those sessions in time slots that would be more convenient for your time zone. Obviously, I am referring to FS track sessions. Cross track sessions are going to be harder to accommodate, but I can try. Thanks, Amir. [1] https://lore.kernel.org/linux-fsdevel/FF0202C3-7500-4BB3-914B-DBAA3E0EA3D7@xxxxxxxxxx/ [2] https://lore.kernel.org/linux-fsdevel/?q=LSF+TOPIC+-re+d%3A4.months.ago..
