Re: Nanosecond fs timestamp support: sad

[Matt Mackall]

On Fri, 2011-07-22 at 16:33 +1000, NeilBrown wrote:
> On Thu, 21 Jul 2011 23:01:24 -0700 Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> 
> > Matt Mackall <mpm@xxxxxxxxxxx> writes:
> > 
> > 
> > > This means I can touch a file something like 70k times per second and
> > > get only 300 distinct timestamps on my laptop. And only 100 distinct
> > > timestamps on a typical distro server kernel.
> > 
> > You should use the inode generation number if you really want
> > to see every update.
> 
> I assume you mean i_version which gets incremented (under a spinlock) if the
> filesystem asks for it.

Indeed. Only usefully exists on ext4 and requires extra system calls.

> This doesn't let you compare the ages of two files.  I wonder if that is
> important.  Is it important to you Matt?

Sort of. We track a 'latest seen timestamp' so we can consider files
before that time unchanged and we need only concern ourselves with the
looking for invisible changes that occur inside that quantum.

> I imagine a scheme where 'stat' would set a flag if it wasn't set, and
> file_update_time would:
>   - if the flag is set, use gettimeofday and clear the flag
>   - if the flag is not set, use jiffies
> 
> so if you are looking, you will see i_mtime changing precisely but if not,
> you don't pay the price.

Hmm, interesting.

> This wouldn't allow precise ordering of distinct files either of course.

Yeah, I don't think we want to introduce observable non-causality in
filesystem time. There might be something clever we can do here, but it
would require some Deep Thought. But if successful, we could mitigate
some of the repeated inode dirtying caused by jiffies-resolution
timestamping.

-- 
Mathematics is the supreme nostalgia of our time.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/