On Sat, 2023-04-15 at 14:35 +0300, Amir Goldstein wrote: > 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. > Agreed. I think we'll need an hour for the nfsd BoF. I probably don't need a full 30 min slot for this topic, between the nfsd BoF and hallway track. I've started a TOPIC email for this about 5 times now, and keep deleting it. I think most of the more controversial bits are pretty much settled at this point, and the rest (crash resilience) is still too embryonic for discussion. I might want a lightning talk at some point about what I'd _really_ like to do long term with the i_version counter (basically: I want to be able to do a write that is gated on the i_version not having changed). > 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.. -- Jeff Layton <jlayton@xxxxxxxxxx>
