The alternate-directory-layout question has only historic value, there is no way

to obtain reliable information from a modern HDD about cylinder groups.

No objection from:	mckusick
Approved by:		bcr (mentor)
This commit is contained in:
Eitan Adler 2013-01-16 04:30:24 +00:00
parent 8037d8de46
commit 505d5517ea
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=40646

View file

@ -8672,40 +8672,6 @@ hint.sio.7.irq="12"</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question id="alternate-directory-layout">
<para>What about alternative layout policies for
directories?</para>
</question>
<answer>
<para>In answer to the question of alternative layout policies
for directories, the scheme that is currently in use is
unchanged from what I wrote in 1983. I wrote that policy
for the original fast file system, and never revisited it.
It works well at keeping cylinder groups from filling up.
As several of you have noted, it works poorly for find.
Most file systems are created from archives that were
created by a depth first search (aka ftw). These
directories end up being striped across the cylinder groups
thus creating a worst possible scenario for future depth
first searches. If one knew the total number of directories
to be created, the solution would be to create
<literal>(total&nbsp;/&nbsp;fs_ncg)</literal> per cylinder
group before moving on. Obviously, one would have to create
some heuristic to guess at this number. Even using a small
fixed number like say 10 would make an order of magnitude
improvement. To differentiate restores from normal
operation (when the current algorithm is probably more
sensible), you could use the clustering of up to 10 if they
were all done within a ten second window. Anyway, my
conclusion is that this is an area ripe for
experimentation.</para>
<para>&a.mckusick;, September 1998</para>
</answer>
</qandaentry>
<qandaentry>
<question id="kernel-panic-troubleshooting">
<para>How can I make the most of the data I see when my kernel