Change default VFS timestamp precision?

[Poul-Henning Kamp]

--------
In message <CAJ-Vmokom24Hv1MNNJz2t_bL_o7X+W6FgXaPXT2Q3gSurKefcg at mail.gmail.com>
, Adrian Chadd writes:

>> A millisecond is pushing it, all things considered, it would have to
>> be an utterly trivial source file for a utterly trivial language.
>
>Why? Computers can do a ridiculous amount of work in a millisecond.

Yes, but try it yourself, they mostly don't.

One millisecond is only about a million instructions if you are lucky,
and in difference from system III, we have put an awful lot of code
between the stuff you want done and the hardware that does it.

So show me, and I'll belive you.

>Right, but using TSP_NSEC only makes sense if (a) we get actual
>nanosecond precision, and (b) we have some guarantee that when you
>modify a file, the timestamp value is at least incremented by say, a
>nanosecond.

No.

TSP_NSEC makes sense if TSP_HZ isn't enough, and it is the next
logical step we can provide.

If you want better than TSP_NSEC, the first thing to do is beat
Intel and AMD up until the provide better timekeeping hardware in
their CPUs.  Once that's done, use this hardware for timecounters
and TSP_NSEC will automatically improve.

>I've been bitten by this - and I've had to hack things up to increment
>a nanosecond counter to treat it as a poor mans generation counter,

That's Lamports (in)famous solution :-)

However, this doesn't really have *anything* to do with VFS timestamps,
because there is NFW the objects you were timestamping were VFS
files if nanosecond resolution were required.

VFS timestamps are a performance trade-off, and if you want TSP_NSEC
you can set TSP_NSEC, but for a sensible default TSP_HZ is the thing.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.