Managing RAID on Linux - Derek Vadala [109]
# mke2fs -b 1024 -i 2048 /dev/md0
This arrangement might be useful for a system where you expect to find many small files, varying in size from 1 to 2 KB. mke2fs also lets you specify the number of inodes without attempting to compute the value. Use the -N flag to pass a fixed number of inodes to mke2fs.
# mke2fs -N 8960896 /dev/md0
Tuning ext2 Filesystems
As I mentioned in the previous section, tune2fs can configure variables associated with an already initialized ext2 filesystem. In addition, there are a number of other tactics that you can use to improve the performance of an ext2 partition: software-RAID-specific options for mke2fs, mount options, and filesystem attributes.
Reserved space
ext2 sets aside a fixed amount of space, by default, for the super-user. This reserved space is supposed to ensure that essential processes, usually running with a UID or GID of root, are able to continue writing data, even after the filesystem becomes full for normal users. In practice, nonprivileged users and processes are often able to unintentionally bypass this safeguard, so it's not really a reliable security mechanism.
By default, 5 percent of the total disk space is reserved when an ext2 filesystem is created. Using the -m flag, users can adjust this percentage to meet their needs. An integer value between 1 and 100 must be used. In this example, 10 percent of the total disk space is reserved:
# mke2fs -m 10 /dev/md0
It might also be useful to change the user who is allowed to write data to the reserved disk space. Since security is such a well-publicized issue these days, many programs no longer run as root. Therefore, you might find it useful to allow the user account under which your database runs, for instance, to have access to the reserved areas on certain partitions. Use the tune2fs command to modify the reserved blocks UID and group. It's safe to make this change while the filesystem is mounted.
# tune2fs -u mysql -g mysql /dev/md0
tune2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Setting reserved blocks gid to 75
Setting reserved blocks uid to 75
There is some confusion surrounding the need for reserved space under ext2. Many administrators create ext2 filesystems without any reserved space, or with the minimum amount (1 percent), when working with extremely large partitions. Their reasoning is that when the reserved space option was introduced, even big partitions were small by today's standards. So reserving the default 5 percent on a partition typical for large systems, such as 40 GB, is perceived as a waste of valuable disk space. Generally, the super-user doesn't need that much reserved space because partitions that large are normally user partitions such as /home.
However, reserved space is essential for minimizing file fragmentation. Fragmentation occurs as filesystems become increasingly full. As space on a disk decreases, it becomes more unlikely that large files can be stored in contiguous disk blocks. Because the file must be spread across different parts of the disk, the actuator arm needs to move more frequently to access those fragmented files. The result is slower disk performance.
Theodore Ts'o, an ext2 developer, advises:
As the [filesystem] get[s] progressively full, the chance for fragmentation goes up. So it is appropriate to use a constant percentage of the total filesystem size for the reserved space. If you have a 500GB array, using 25GB of reserved space is therefore not necessarily overkill. It sounds like a lot of space, but it's still only 5 percent of the total filesystem.
The dangers of fragmentation present themselves only when a filesystem changes. Therefore, reserved space might not be needed at all when data is static. For example, an array serving large images that never change (perhaps from a popular space telescope), might require a filesystem that doesn't waste any space. Simply adding new images, without erasing