Date: Sun, 24 Nov 2013 22:44:32 +0000 (UTC) From: John-Mark Gurney <jmg@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43236 - head/en_US.ISO8859-1/books/faq Message-ID: <201311242244.rAOMiWHa049734@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: jmg (src committer) Date: Sun Nov 24 22:44:32 2013 New Revision: 43236 URL: http://svnweb.freebsd.org/changeset/doc/43236 Log: bring this FAQ entry into this millenia, we've defaulted to UFS2 for around 10 years now, and the entry talked about old UFS1 limits... it also talked about old defaults for black and fragment sizes too... With the current defaults, full fsck memory requirements are 32MB/TB Reviewed by: mckusick, -doc 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 Sun Nov 24 19:02:22 2013 (r43235) +++ head/en_US.ISO8859-1/books/faq/book.xml Sun Nov 24 22:44:32 2013 (r43236) @@ -1338,92 +1338,25 @@ </question> <answer> - <para>For FFS file systems, the maximum theoretical limit is - 8 TB (2 G blocks), or 16 TB for the default - block size of 8 KB. In practice, there is a soft limit - of 1 TB, but with modifications file systems with - 4 TB are possible (and exist).</para> + <para>For FFS file systems, the largest file system is practically + limited by the amount of memory required to &man.fsck.8 the file + system. &man.fsck.8 requires one bit per fragment, which with + the default fragment size of 4&nbps;KB equates to 32&nbps;MB + of memory per TB of disk. This does mean that on architectures + which limit userland processes to 2&nbps;GB (e.g., &i386;), + the maximum &man.fsck.8'able filesystem is ~60&nbps;TB.</para> + + <para>If there was not a &man.fsck.8 memory limit the maximum + filesystem size would be 2&nbps;^&nbps;64 (blocks) * 32&nbps;KB + => 16 Exa * 32&nbps;KB => 512 ZettaBytes.</para> <para>The maximum size of a single FFS file is approximately - 1 G blocks, or 4 TB with a block size of - 4 KB.</para> - - <table> - <title>Maximum File Sizes</title> - - <tgroup cols="3"> - <thead> - <row> - <entry>FS Block Size</entry> - - <entry>Works</entry> - - <entry>Should Work</entry> - </row> - </thead> - - <tbody> - <row> - <entry>4 KB</entry> - - <entry>> 4 GB</entry> - - <entry>4 TB - 1</entry> - </row> - - <row> - <entry>8 KB</entry> - - <entry>> 32 GB</entry> - - <entry>32 TB - 1</entry> - </row> - - <row> - <entry>16 KB</entry> - - <entry>> 128 GB</entry> - - <entry>32 TB - 1</entry> - </row> - - <row> - <entry>32 KB</entry> - - <entry>> 512 GB</entry> - - <entry>64 TB - 1</entry> - </row> - - <row> - <entry>64 KB</entry> - - <entry>> 2048 GB</entry> - - <entry>128 TB - 1</entry> - </row> - </tbody> - </tgroup> - </table> - - <para>When the FS block size is 4 KB, triple indirect - blocks work and everything should be limited by the maximum FS - block number that can be represented using triple indirect - blocks (approx. - 1024<superscript>3</superscript> + 1024<superscript>2</superscript> + 1024), - but everything is limited by a (wrong) limit of - 1 G - 1 on FS block numbers. The limit on FS - block numbers should be 2 G - 1. There are - some bugs for FS block numbers near 2 G - 1, - but such block numbers are unreachable when the FS block - size is 4 KB.</para> - - <para>For block sizes of 8 KB and larger, everything - should be limited by the 2 G - 1 limit on FS - block numbers, but is actually limited by the - 1 G - 1 limit on FS block numbers. Using the - correct limit of 2 G - 1 blocks does cause - problems.</para> + 2 PB with the default block size of 32 KB. Each + 32 KB block can point to 4096 blocks. With triple + indirect blocks, the calculation is 32&nbps;KB * 12 + + 32&nbps;KB * 4096 + 32&nbps;KB * 4096^2 + 32&nbps;KB * + 4096^3. Increasing the block size to 64 KB will increase + the max file size by a factor of 16.</para> </answer> </qandaentry>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201311242244.rAOMiWHa049734>