What are the limits for ffs filesystems?
For ffs filesystems, the maximum theoretical limit is 8 terabytes (2G blocks), or 16TB for the default block size of 8K. In practice, there is a soft limit of 1 terabyte, but with modifications filesystems with 4 terabytes are possible (and exist).
The maximum size of a single ffs file is approximately 1G blocks (4TB) if the block size is 4K.
Table 3-1. Maximum file sizes
| fs block size | 2.2.7-stable | 3.0-current | works | should work |
|---|---|---|---|---|
| 4K | 4T-1 | 4T-1 | 4T-1 | >4T |
| 8K | >32G | 8T-1 | >32G | 32T-1 |
| 16K | >128G | 16T-1 | >128G | 32T-1 |
| 32K | >512G | 32T-1 | >512G | 64T-1 |
| 64K | >2048G | 64T-1 | >2048G | 128T-1 |
When the fs block size is 4K, triple indirect blocks work and everything should be limited by the maximum fs block number that can be represented using triple indirect blocks (approx. 1K^3 + 1K^2 + 1K), but everything is limited by a (wrong) limit of 1G-1 on fs block numbers. The limit on fs block numbers should be 2G-1. There are some bugs for fs block numbers near 2G-1, but such block numbers are unreachable when the fs block size is 4K.
For block sizes of 8K and larger, everything should be limited by the 2G-1 limit on fs block numbers, but is actually limited by the 1G-1 limit on fs block numbers, except under -STABLE triple indirect blocks are unreachable, so the limit is the maximum fs block number that can be represented using double indirect blocks (approx. (blocksize/4)^2 + (blocksize/4)), and under -CURRENT exceeding this limit may cause problems. Using the correct limit of 2G-1 blocks does cause problems.
XML Feeds