[RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)

[RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)

[Al Boldi]

Al Boldi wrote:
> Jakob Oestergaard wrote:
> > Why on earth would you cripple the kernel defaults for ext3 (which is a
> > fine FS for boot/root filesystems), when the *fundamental* problem you
> > really want to solve lie much deeper in the implementation of the
> > filesystem?  Noatime doesn't solve the problem, it just makes it "less
> > horrible".
>
> inotify could easily solve the atime problem, but it's got the drawback of
> forcing the user to register each and every file/dir of interest, which
> isn't really reasonable on TB-filesystems.
>
> It could be feasible to introduce mnotify, which would notify the user of
> meta changes, like atime, across the filesystem.  Something like mnotify
> could also be helpful in CoW situations, provided it supported an in-sync
> interface.

Here is an idea:  Could FUSE be used to produce mnotify behaviour?


Thanks!

--
Al

Re: [RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)

[Jan Engelhardt]

On Aug 12 2007 06:32, Al Boldi wrote:
>Al Boldi wrote:
>> Jakob Oestergaard wrote:
>> > Why on earth would you cripple the kernel defaults for ext3 (which is a
>> > fine FS for boot/root filesystems), when the *fundamental* problem you
>> > really want to solve lie much deeper in the implementation of the
>> > filesystem?  Noatime doesn't solve the problem, it just makes it "less
>> > horrible".
>>
>> inotify could easily solve the atime problem, but it's got the drawback of
>> forcing the user to register each and every file/dir of interest, which
>> isn't really reasonable on TB-filesystems.

What inotify needs is some kind of SUBDIR flag on a watch so that one does not
run out of fds, then the TB issue becomes a bit lighter I think.

>> It could be feasible to introduce mnotify, which would notify the user of
>> meta changes, like atime, across the filesystem.  Something like mnotify
>> could also be helpful in CoW situations, provided it supported an in-sync
>> interface.
>
>Here is an idea:  Could FUSE be used to produce mnotify behaviour?

It may, and in some cases, not. For example, I only had a single filesystem,
and would like atime notificatios for it, then how would I do that? What comes
to mind is to use a fuse fs that mirrors, but also notifies, ergo:
	mount -t fuse.lomount / /mnt
Well, wonderful, now I still need to pivot_root to /mnt, so that all accesses
actually end up in fuse-land. And this gets ugly on shutdown, when things have
to be unmounted.


	Jan
-- 

Re: [RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)

[Nicholas Miell]

On Sun, 2007-08-12 at 13:24 +0200, Jan Engelhardt wrote:
> On Aug 12 2007 06:32, Al Boldi wrote:
> >Al Boldi wrote:
> >> Jakob Oestergaard wrote:
> >> > Why on earth would you cripple the kernel defaults for ext3 (which is a
> >> > fine FS for boot/root filesystems), when the *fundamental* problem you
> >> > really want to solve lie much deeper in the implementation of the
> >> > filesystem?  Noatime doesn't solve the problem, it just makes it "less
> >> > horrible".
> >>
> >> inotify could easily solve the atime problem, but it's got the drawback of
> >> forcing the user to register each and every file/dir of interest, which
> >> isn't really reasonable on TB-filesystems.
> 
> What inotify needs is some kind of SUBDIR flag on a watch so that one does not
> run out of fds, then the TB issue becomes a bit lighter I think.
> 

There's no risk of running out of fds; inotify only requires one. You
still have to register every directory you're interested in, though, but
that's a limitation caused by the Unix VFS philosophy and the resulting
filesystem design it inspired rather than of inotify itself.

Come up with a filesystem where given an inode you can find every
directory that has links to that inode with very little effort, convince
everybody to switch from ext3 to this new filesystem, and then maybe
inotify could start doing recursive subtree watches. Otherwise, it's
just not feasible.

-- 
Nicholas Miell <nmiell@comcast.net>