[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c0942db0707250902v58e23d52v434bde82ba28f119@mail.gmail.com>
Date: Wed, 25 Jul 2007 09:02:56 -0700
From: "Ray Lee" <ray-lk@...rabbit.org>
To: "Rene Herman" <rene.herman@...il.com>
Cc: 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/24/07, Rene Herman <rene.herman@...il.com> wrote:
> Yes, but what's locate's usage scenario? I've never, ever wanted to use it.
> When do you know the name of something but not where it's located, other
> than situations which "which" wouldn't cover and after just having
> installed/unpacked something meaning locate doesn't know about it yet either?
I use it to find source files and documents all the time. One of my
work boxes has <runs a locate work | wc -l> ~38500 files and
directories under my source directory. And then there's the "I wrote
that tech doc two years ago, where was that. Hmm, what did I name it?
Bet it had 323 in the name, and doc in the path."
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.
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