2008/1/18, Linus Torvalds <[EMAIL PROTECTED]>: > > > 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.
The current solution doesn't hit the performance at all when compared to the competitor POSIX-compliant systems. It is faster and does even more than the POSIX standard requires. Please see the test results I've sent into the thread "-v6 0/2": http://lkml.org/lkml/2008/1/18/447 I guess, the current solution is ready to use. > > Linus > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
