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

[nf <nf2 scheinwelt at>]

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