Re: Inotify

On Thu, 2004-10-07 at 08:45 -0500, Jon Trowbridge wrote:
> Huh?  A couple of years in the future, I hope that inotify is in the
> mainline kernel so that everyone just has it.  And regardless of what
> the kernel folks do, the commercial distros will probably ship it in
> their kernels.  Novell certainly will, and I suspect RH will too.

Perhaps two years was a little pessimistic, but I'm coming from the
point of view of a Debian user. ;-)

Seriously though, some people are still using 2.2 kernels now - kernel
upgrades can take longer to propagate than upgrades to other software.

Also, perhaps more importantly, not everyone runs Linux.  Perhaps all
operating systems that Gnome runs on provide a kernel level equivalent
to inotify, but if not then some non-kernel dependent solution is going
to be needed for them.

> Besides being *massively* inefficient, polling the filesystem gives us
> less information that inotify.  For example, if someone does "mv foo
> bar" inotify will tell us that the file foo is now bar.  With polling,
> all we can know is that foo is gone and that bar has appeared.  This
> actually matters, because it means that you'd lose all
> non-file-derivable metadata every time a file is renamed.

I absolutely agree that filesystem polling is massively inferior to
inotify.  However, being unable to run beagle at all is inferior to
being able to run beagle with reduced responsiveness to filesystem

To be honest, most of my files don't actually change very often, and
when I'm searching I'm usually looking for something I modified more
than a day ago, rather than a document I've just been working on.

Perhaps the question I should ask is: if I implemented a patch providing
a filesystem polling based substitute to inotify, would it be accepted?
Assuming it had decent code quality, etc, of course.

What is the non-file-derivable metadata you refer to?  I haven't
properly got an overview of the planned architecture of beagle in my
head, yet.  If beagle is going to absolutely depend on such things,
perhaps it does make a filesystem polling solution unworkable...

Richard Boulton <richard tartarus org>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]