[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Inode/Blocksize questions

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]