Date: Wed, 16 Jan 2013 04:30:24 +0000 (UTC) From: Eitan Adler <eadler@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r40646 - head/en_US.ISO8859-1/books/faq Message-ID: <201301160430.r0G4UONZ075965@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: eadler Date: Wed Jan 16 04:30:24 2013 New Revision: 40646 URL: http://svnweb.freebsd.org/changeset/doc/40646 Log: 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) Modified: head/en_US.ISO8859-1/books/faq/book.xml Modified: head/en_US.ISO8859-1/books/faq/book.xml ============================================================================== --- head/en_US.ISO8859-1/books/faq/book.xml Tue Jan 15 20:53:43 2013 (r40645) +++ head/en_US.ISO8859-1/books/faq/book.xml Wed Jan 16 04:30:24 2013 (r40646) @@ -8673,40 +8673,6 @@ hint.sio.7.irq="12"</programlisting> </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 / 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 panics?</para>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301160430.r0G4UONZ075965>