On Mon, Apr 29, 2002 at 02:56:30PM -0500, Matt Stegman wrote: > > A smaller blocksize will generally result in slower performance. On the > other hand, you'll lose less space per file with a smaller blocksize. In general, the amount of space which is "wasted" given a particular blocksize is one-half the block size. So using a 1k filesystem, on average you will waste 512 bytes per file. Using a 4k filesystem, on average you will waste 2k per file. If the average size message size is 9k, then the overhead of using maildir based system is about 5.5% with 1k blocksize, and about 22.2% using a 4k blocksize. For files as small as single mail messages (i.e., averaging about 8-9k, rarely as larger than half a meg except for Windows virus messages), the performance gain for using a 4k blocksize is probably not all that great. So you might want to use a 1k blocksize just to minimize the overhead. > With default options, the number of inodes mke2fs creates is 1 per 8kB of > disk space. In other words, mke2fs creates enough inodes for the case where the average size of a file on the filesystem is larger than 8k. If you think you will be receiving a large number of small messages, it might be wise to set the bytes-per-inode setting (via the -i option of mke2fs) to 4096. This will mean the filesystem will have enough inodes even if the average file size is as small as 4k. > Inodes used by a file is always one (unless you have multiple links > pointing to the file). Incorrect; a file always uses one inode, regardless of how many hard links you might have. Other "special" files also consume inodes, such as symbolic links, named pipes, unix domain sockets, block and character device files, etc., but that all falles under the general rule of one file, one inode. > If you're really worried about space efficiency, then as bad as it may be > to say on the ext3-users list, you may want to consider reiserfs - it > usually benchmarks faster on small files (where "small" is under 15kB, I > think), and is more space-efficient then ext2/3, if you enable tail > packing. Reseirfs benchmarks faster if you have large directories. That's actually going to be the major problem if you're using maildir, is that large number of files per directory. The indexed directory extension to ext2/3 will solve this problem, but it's not quite ready for production use quite yet. On the other hand, note that there have been some reports about reseirfs not handling I/O errors and disk corruption very well. Personally, I consider reliability far more important than performance, especially for a filesystem containing e-mail.... - Ted
