[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c0942db0707251428r7a6a1cc9seea8dc59020f1bcb@mail.gmail.com>
Date: Wed, 25 Jul 2007 14:28:24 -0700
From: "Ray Lee" <ray-lk@...rabbit.org>
To: "Zan Lynx" <zlynx@....org>
Cc: "Rene Herman" <rene.herman@...il.com>, david@...g.hm,
"Nick Piggin" <nickpiggin@...oo.com.au>,
"Jesper Juhl" <jesper.juhl@...il.com>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"ck list" <ck@....kolivas.org>, "Ingo Molnar" <mingo@...e.hu>,
"Paul Jackson" <pj@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: -mm merge plans for 2.6.23
On 7/25/07, Zan Lynx <zlynx@....org> wrote:
> On Wed, 2007-07-25 at 09:02 -0700, Ray Lee wrote:
>
> > I'd just like updatedb to amortize its work better. If we had some way
> > to track all filesystem events, updatedb could keep a live and
> > accurate index on the filesystem. And this isn't just updatedb that
> > wants that, beagle and tracker et al also want to know filesystem
> > events so that they can index the documents themselves as well as the
> > metadata. And if they do it live, that spreads the cost out, including
> > the VM pressure.
>
> That would be nice. It'd be great if there was a per-filesystem inotify
> mode. I can't help but think it'd be more efficient than recursing
> every directory and adding a watch.
>
> Or maybe a netlink thing that could buffer events since filesystem mount
> until a daemon could get around to starting, so none were lost.
See "Filesystem Event Reporter" by Yi Yang, that does pretty much
exactly that. http://lkml.org/lkml/2006/9/30/98 . Author had things to
update, never resubmitted it as far as I can tell.
Ray
-
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