Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mappedfiles

From: Linus Torvalds
Date: Fri Jan 18 2008 - 14:37:38 EST




On Fri, 18 Jan 2008, Miklos Szeredi wrote:
>
> What I'm saying is that the times could be left un-updated for a long
> time if program doesn't do munmap() or msync(MS_SYNC) for a long time.

Sure.

But in those circumstances, the programmer cannot depend on the mtime
*anyway* (because there is no synchronization), so what's the downside?

Let's face it, there's exactly three possible solutions:

- the insane one: trap EVERY SINGLE instruction that does a write to the
page, and update mtime each and every time.

This one is so obviously STUPID that it's not even worth discussing
further, except to say that "yes, there is an 'exact' algorithm, but
no, we are never EVER going to use it".

- the non-exact solutions that don't give you mtime updates every time
a write to the page happens, but give *some* guarantees for things that
will update it.

This is the one I think we can do, and the only things a programmer can
impact using it is "msync()" and "munmap()", since no other operations
really have any thing to do with it in a programmer-visible way (ie a
normal "sync" operation may happen in the background and has no
progam-relevant timing information)

Other things *may* or may not update mtime (some filesystems - take
most networked one as an example - will *always* update mtime on the
server on writeback, so we cannot ever guarantee that nothing but
msync/munmap does so), but at least we'll have a minimum set of things
that people can depend on.

- the "we don't care at all solutions".

mmap(MAP_WRITE) doesn't really update times reliably after the write
has happened (but might do it *before* - maybe the mmap() itself does).

Those are the three choices, I think. We currently approximate #3. We
*can* do #2 (and there are various flavors of it). And even *aiming* for
#1 is totally insane and stupid.

Linus
--
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/