[LUNI] file system limitations

[Steven Lembark]

-- Erik Lickerman <elickerman at ameritech.net>

> I explained a bit more about the system in my last post but you raise an
> interesting point.  Each directory will have a small number of files in
> it, less than ten.  I would however have a parent directory which
> contains all these directories so that parent parent directory could have
> 10,000 directories in it.  You seem to be suggesting I would get better
> performance if my structure weren't as flat, i.e. I figure out an
> predictible way to have these ten thousand directories which contain the
> files of interest, to be a few more steps down the directory tree.  Is
> that correct?

You will save considerable time if the directory tree were
3 levels deep in this case. The issue is that dir's are
sequentially searched. One good way is to hash the files
by name and use the 1-, 2-, and 3-character leading strings
as subdirs:

	./foo/a
		./aa
			./aaa
			./aab
			...
			./zzz
		./ab
			./aaa
			...
			./zzz

If the hash were reliable this would give you 10_000 / 676,
or around 20 directrories in each directory. The tree below
./foo would be quidkly determined by any file name and find
on the files would be quick enough because the tree is only
3 levels deep.

This would also be reasonable for backups since you could
grab any directory below ./foo using the file names quickly
enough (or use cpio and get */foo/*/filename to get anything
back you needed).

--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582