Messages in this thread | | | Date | Thu, 12 Aug 1999 09:34:01 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: problems with large directories - not only ext2 |
| |
On Tue, 10 Aug 1999, Marc Lehmann wrote:
> On Mon, Aug 09, 1999 at 11:28:03PM +0200, Hermann Schichl <herman@esi.ac.at> wrote: > > > > > This is not a situation of Linux (IMHO) but one of UNIX. Most Unices > > show this behaviour. Probably if you try ls -fR, times should go linearly > > with directory size. > > As I said, this has nothing to do with ext2 being slow with large directories > (or any fs being slow).
O(n^2) - both ext2 and isofs do linear search in directories.
> I would _not_ mind "find" being slow, esp. since this is going to be fixed > in 2.3. > > I _do_ mind my whole system getting slow just because some background > process runs find. And yes, the whole system gets slow and _very_ > sluggishly.
Have you profiled it?
> This happens only while scanning large directories. My "theory du jour" > is that the dcache operations are single-cpu and - in this case - very time > consuming.
BS. The only places where it would affect the things are shrink_dcache_parent() and d_invalidate(). Not going to happen with normal find(1) stuff. Besides, solution should not be SMP-only.
> That (or something similar, as my theory is most probably wrong) would > explain why my dual cpu system gets so sluggishly while just doing "find", > which should be very i/o intensive but nothing else.
What arguments are you passing to find(1)?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |