Re: mnotify: mixing nonotify & simple mount watching (Was: Re: [RFC/PATCH] Nonotify...)

[John McCutchan <ttb tentacle dhs org>]

Just to remind people who are interested in this problem:

Inotify patches for linux-2.6.7 were posted on the gamin list recently,
and using gamin CVS everything works perfeclty, and doesn't block
unmount. In short: this problem has been solved and I haven't found a
bug in inotify in 2 weeks.

John

On Fri, 2004-08-13 at 21:01, nf wrote:
> On Sat, 2004-08-14 at 00:27, Danny Milosavljevic wrote:
> > Hi,
> > 
> > Am Freitag, den 13.08.2004, 22:14 +0200 schrieb nf:
> > 
> > > Maybe it would be sufficient to store the file modification dates not
> > > only in the parent directories but also in a field in the device
> > > superblock: The userspace client would only have to poll the
> > > 'mcontents_mtime' [1] of the mounted devices and, only if it has
> > > changed, poll the 'dcontents_mtime' [2] of the directories on the
> > > device. That would also reduce the idle activity to almost zero, but
> > > without the need of a complex event queuing and grouping mechanism
> > > inside the kernel. (But to be honest, i don't know how that kernel event
> > > stuff works).
> > > 
> > > [1] Mountpoint contents modification time
> > > [2] Directory contents modification time
> > ^-- hmm...
> > 
> > Keep in mind that directory mtimes have pretty unexpected semantics. If
> > you have a directory "a" which in turn has a directory "b" which in turn
> > contains file "c", if you change file "c", for some reason *only* the
> > mtime of the directory "b" get updated. 
> > (I'd either think that it would be *supposed* to be either: 1) *only*
> > the mtime of the file be updated or 2) the mtime of the directory "b" be
> > updated, that would trigger updating the mtime of the directory "a")
> > 
> > a     <-- 3. mtime, unchanged
> > +--b  <-- 2. mtime, changed
> >    +-- c <-- 1. file, changed
> > 
> > At least I think it is that way, but I have to say that I never quite
> > understood that kind of inconsistency so I might be wrong.
> 
> Nonotify uses its own field "i_dcontents_mtime" in the inode structure
> to store the last modification time of files in the directory. It does
> not use the 'mtime' field, because i didn't want to break the 'standard'
> behavior (which you are describing). I think 'mtime' only changes, when
> a file is added or deleted from the directory, but not when a file is
> being modified.
> 
> Norbert
>  
> 
>