Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.questions
Subject: Re: Computational complexity of rm & ls
Message-ID: <7941@chinet.chi.il.us>
Date: 15 Mar 89 16:56:14 GMT
References: <9000012@m.cs.uiuc.edu> <9000014@m.cs.uiuc.edu> <7919@chinet.chi.il.us> <16364@mimsy.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 22

In article <16364@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <7919@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell)
>writes:
>>The maximum optimal size probably varies with the OS version.  I've
>>been told that directory access becomes much less efficient when
>>the directory inode goes to triple indirect blocks (300 files?).
>
>300?!?  (Maybe 300! :-) [read `300 factorial'])


OK, OK.. indirect blocks, not triple indirect blocks.  Shows how much
you miss when all you have to go by is the man pages.  Back to the
subject though, a simple-minded test of catting 1000 tiny files
in one directory to /dev/null vs. 100 files in each of 10 directories
using xargs and explicit filenames so shell expansion would not be
a factor showed that the large directory took about twice the sys
time.  This confirmes my more casual observations that having large
directories on a machine hurts performance in general, at least under
SysV.  The worst case seems to be accessing large directories on a
remote machine using RFS.

Les Mikesell