UFS Subdirectory limit.

[Don Lewis]

On 28 Mar, David Malone wrote:
> Here's the benchmark results comparing a two level scheme (which
> I've labeled "sqrt") with a single directory with 150000 subdirectories
> (which I've labeled "flat").
> 
> The benchmark is in 4 phases:
> 
> 	mkdir) This builds the directory structure.
> 	write) This writes a small amount of data into 100000 files
> 	       in a pseudo random sequence of subdirectories.
> 	read)  This reads back the data from each of the 100000
> 	       files (in the same order they were written).
> 	rm)    This does an "rm -fr" of the whole tree.
> 
> I just used /usr/bin/time on each phase and synced out the data
> between each phase. The results (averaged over 4 runs, see the end
> of the mail for the output of ministat on the data).
> 
>            real time               user time               sys time
>      mkdir write read   rm | mkdir write read   rm | mkdir write read    rm
> sqrt  499   4302 2409 1569 |  1.84  1.94 1.72 1.69 |  29.9 33.5  21.3 161.6
> flat 1172   4318 2407 1717 |  1.47  1.62 1.52 1.66 |  26.1 33.5  20.6 158.1
> 
> So, it seems that while making the directory structure takes a bit
> longer for the flat method, there's no significant penality in real
> time for using it. The user times are pretty irrelevant (though the
> flat scheme is slightly faster, probably because some of the phases
> don't do sqrts ;-).
> 
> Interestingly, the system times for the flat structure are actually
> *better* than the two level structure! I think this supports Don's
> suggestion that the layout of data on the disk with very large
> directories is not as good as it could be.

Just for grins, you might want to try a "very-flat" experiment where you
create all 100000 files in the top directory.

Traditionally directories were always allocated in another cylinder
group than their parent, which would spread them all over the disk.
This turns out to be somewhat sub-optimal because it causes an excessive
amount of seek activity when traversing large directory trees.  When the
dirpref code was added, it allowed a limited number of subdirectories to
be allocated using the same cylinder group as their parent, but I
suspect that the allocations will still be fairly well distributed when
running your benchmark.