Xref: utzoo comp.unix.wizards:15648 comp.unix.questions:12960
Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!srcsip!nic.MR.NET!hal!ncoast!allbery
From: allbery@ncoast.ORG (Brandon S. Allbery)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: unix question: files per directory
Message-ID: <13577@ncoast.ORG>
Date: 18 Apr 89 01:50:11 GMT
References: <24110@beta.lanl.gov> <6576@cbmvax.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Distribution: na
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 46

As quoted from <6576@cbmvax.UUCP> by grr@cbmvax.UUCP (George Robbins):
+---------------
| In article <24110@beta.lanl.gov> dxxb@beta.lanl.gov (David W. Barts) writes:
| > How many files can there be in a single UNIX directory
| > (I realize this may depend on the variety of UNIX; I expect
| > the Berkeley fast file system would allow more)?  I need
| > a better answer than "a lot" or "at least 2000", if possible.
| 
| At least 33,000  8-) 
| 
| I recently played with an archive of comp.sys.amiga from day 1 and
| it was on this order.  
+---------------

System V has no limit, aside from maximum file size (as modified by ulimit,
presumably).  As a PRACTICAL limit, when your directory goes triple-indirect,
it is too slow to search in a reasonable amount of time.  Assuming the
standard 2K block size of SVR3, this is (uhh, let's see... 2048 bytes/block
/ 16 bytes/dirent = 128 dirent/block; times 10 is 1280 dirent direct, add
single-indirect = 128 * 512 pointers/block [2048 / 4 bytes/pointer] = 65,536
entries single-direct; multiply that by 512 to get double-indirect)
33,621,248 directory entries before you go triple-indirect.  (I personally
think that even going single-indirect gets too slow; 1280 directory entries
is more than I ever wish to see in a single directory!  But even limiting to
single-indirect blocks, you get 66,816 directory entries.)  (I included the
math deliberately; that number looks way too large to me, even though I
worked the math twice.  Maybe someone else in this newsgroup can
double-check.  Of course, I'm no Obnoxious Math Grad Student ;-)

The Berkeley FFS is still based on direct and indirect blocks (it's how
they're arranged on the disk that speeds things up); however, directory
entries are not fixed in size in the standard FFS.  (I have seen FFS with
System V directory entries; the two aren't necessarily linked.  But they
usually are, as flexnames are nicer than a 14-character maximum.)  You can't
simply calculate a number; you must figure the lengths of filenames -- and
the order of deletions and additions combined with file name lengths can
throw in jokers, at least on systems without directory compaction.

I have no doubt that if I screwed up somewhere, we'll both hear about it. ;-)

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser