Zhaoming Luo, le sam. 03 mai 2025 08:30:10 +0800, a ecrit: > On Sat, May 03, 2025 at 02:21:31AM +0200, Samuel Thibault wrote: > > Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit: > > > On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote: > > > > Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit: > > > > > Get the time with higher resolution from kernel using > > > > > host_get_time64() > > > > > when possible. > > > > > > > > It seems there's a misunderstanding. I explained that the mapped time > > > > does have 64bit precision fields, that's what I mean we want to use, > > > > rather than the costly RPC. When we discussed about it on IRC, I didn't > > > > know that libdiskfs already uses maptime, so advised to just use the RPC > > > > since it's simpler. But since libdiskfs already uses maptime, better > > > > just extend maptime with 64b capability (falling back to 32b if the 64b > > > > fields are zero). > > > > > > > But the issue is that maptime_read does not support 10ns resolution > > > > Honestly, I believe 10ns resolution is less useful for files timestamps > > than using the effective mapfile vs costly RPC. Files take time to > > write, so it's not unexpected to have coarse resolution for them. > > > I agree, but one of the reason I'm interested in it is that some > software tests require high-precision file timestamps. For example vim: > https://github.com/vim/vim/issues/16658.
There's "high" and "high". The report is about 1s granularity. The maptime interface provides the interrupt granularity, i.e. 10ms, that should be small enough. Samuel
