Considerations when creating ext3 filesystems
|This page is a stub|
You can help Ext2/3/4 Wiki by expanding it.
There are a number of issues that should be considered when creating an ext3 filesystem.
Many administrative issues have to do with how your entire system is partitioned, and how your available disk space is broken up into individual partitions and filesystems. Some of the issues you may wish to consider include:
How do you plan to back up the filesystem? If it is too big, it may make backup more complicated. It is often good idea to separate out data which can be easily recovered or regenerated (which therefore may not need to be backed up) with data which must be backed up frequently and reliably.
It is often a good idea to keep log files that might grow without bound on a separate filesystem from normal files, so that if the log partition overflows, it doesn't prevent the rest of the system from functioning correctly. Hence, it may be a good idea to put a /var/log filesystem on a separate filesystem from /var/spool.
On the other hand, too many partitions can cause wasted space, since unusued space in one filesystem can not be used in another. On the other hand, disk space is generally much cheaper than system administrator time, so often this is not a major concern.
Number of inodes
The number of inodes in the system can not be changed after the filesystem is created, at least without growing the filesystem. If the filesystem is grown using resize2fs (wihch requires increasing the size of the partition or logical volume on which the filesystem resides, of course), the number of inodes in the filesystem will grow, but only in rough proportion to the number of blocks in the filesystem.
The proportion of inodes to disk space available is controlled by the -i option to mke2fs.
There is no harm in creating too many inodes, except that time to fsck the filesystem will grow a small amount, and space that could be used for file storage will be reserved for the inode table.
The default inode size for ext3 filesystems are 128 bytes. A larger inode size can be used to store extended attributes, which can speed certain workloads that use a large number of extended attributes, such as SE Linux or Sambav4. In addition, at least 256 bytes of inodes is required for some ext4 features.
Make sure you have a new enough version of e2fsprogs to support the on-line resizing feature if this is something that you expect that you might need.
Memory needed to fsck the filesystem
The size of disk storage has been growing much more quickly than size of memory generally available on some systems, and so in recent years, it has become easier to create filesystems so large that e2fsck may not function in restricted memory environments. Some of the major uses of memory of e2fsck is for various inode and block bitmaps, as well as for a directory information cache. Specifically, e2fsck uses 3 block bitmaps and up to 6 inode bitmaps (normally only 4 are used, but in some cases more are required). So for a 64GB filesystem which has 16 million 4k datablocks and 8 million inodes, each inode bitmap will take approximately a megabyte, and each block bitmap will consume approximately 2 megabytes, for total memory requirement for bitmaps alone of 12 megabytes. In addition, e2fsck keeps a directory information which requires 12 bytes for each directory. Normally the number of directories is relatively small compared to the number of inodes, but there are some data sets which use a large number of hard links, and an even larger number of directories (since directories can not be hard linked, in hard link farms the number of directories can grow very quickly compared to the disk space consumed). In one case, in a filesystem that had 88 million inodes of which 77 million were directories, the required space necessary for the directory information cache was over 880 megabytes. Unfortunately on a 32-bit system, with some of the address space taken up by dynamically loaded shared libraries, the user ran out of address space, since the total amount of address space available to each process on a 32-bit x86 system is 3 gigabytes.
Hence, if you are creating a very large filesystem, it may be a good idea to consider creating a swap partition and making sure swap is enabled for starting the fsck process. In addition, if you anticipate requiring a large number of directories or want to create very large filesystems, choosing a 64-bit process architecture could be a very good idea.