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
This commit is contained in:
John-Mark Gurney
parent
49f33a1ed8
commit
b90f9f8bc9
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43236
1 changed files with 17 additions and 84 deletions
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue