[LTP] [PATCH] syscalls/statx06: use a fine-grained timestamp for the second time fetch
Jeff Layton
jlayton@kernel.org
Wed May 24 12:11:08 CEST 2023
On Wed, 2023-05-24 at 10:46 +0200, Cyril Hrubis wrote:
> Hi!
> > > Now, it is not a right time to review this patch, I prefer to review
> > > this when your kernel patchset is merged into linux master or
> > > linux-next. Then we can add a comment or a kernel commit id to explain
> > > this..
> > >
> > >
> >
> > Fair enough. I don't think there is any issue with taking this patch in
> > earlier however.
> >
> > The problem with this test is that it makes the assumption that coarse-
> > grained timestamps are sufficient to bracket a filesystem operation.
> > While that has largely been true in the past, it's certainly not
> > specified by any standard.
>
> Do we have any API to ask the kernel what the granularity of filesystem
> the timestamps is? Would that make sense to be added if it's not
> present?
>
No, we don't have such a thing now, and we don't really track that
information in the kernel.
We do have a sb->s_time_gran field which is in units of nanoseconds, but
that really is more about the granularity that the filesystem itself can
store on disk. It doesn't tell you whether the kernel decided to put a
coarse or fine grained timestamp in there.
> Apart from that I think that this patch is fine, since the
> CLOCK_REALTIME value would be between CLOCK_REALTIME_COARSE and
> CLOCK_REALTIME_COARSE + one tick. So the change is backward compatible
> and we will not loose any precision in the assertions either.
>
> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
>
Thanks, and yes. This should be safe to apply now even if the kernel
patch series never goes in.
--
Jeff Layton <jlayton@kernel.org>
More information about the ltp
mailing list