[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1186983541.2717.6.camel@entropy>
Date: Sun, 12 Aug 2007 22:39:01 -0700
From: Nicholas Miell <nmiell@...cast.net>
To: Jan Engelhardt <jengelh@...putergmbh.de>
Cc: Al Boldi <a1426z@...ab.com>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)
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@...cast.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists