Re: Writing a GNOME mail client.

[Drazen Kacar <dave srce hr>]

Warren Young wrote:
> Nathan Clegg wrote:
> > 
> > By giving every message its own file and even splitting a single message
> > into several files, don't we risk running out of inodes on a multi-user
> > system??  I collect hundreds of messages every week from my 15+ mailing
> > lists, compared to the thousands I throw away.  Aren't we also seeing a
> > performance hit if we have to open multiple files everytime we scroll to a
> > single message, or likewise if we have to read, say, 1000 files to open a
> > single folder?
> 
> Inodes in Linux are

And, of course, Linux is the only OS in the universe?

> 32 bits long.  If your machine had 1024 users on it,
> they would each have to have over 4 million files before they overloaded
> an Ext2 filesystem's inode limit.  Before you hit that, you hit other
> limits, like the fact that to exhaust the inodes, you'd have to fill a
> 4TB disk with 1-block files.  (Assumes 1024 bytes per block.  For 4096
> byte blocks, you'd need a 16TB disk before you'd hit the wall.)

There is no OS with 32-bit long inode. However, there are systems whose inode
identifier is 32-bits long. But that's beside the point. There are
a lot of systems with file systems which have fixed number of inodes
and it's determined at the file system's creation time. So you can have
3GB of free disk space, but if you run out of inode space, you won't
be able to create a single file. That's why quota can be set to
file system usage and/or number of files (that would be inodes).

> You may have a valid point, though.  Perhaps it would make sense to pack
> all the subfiles I mentioned into a simple, single file, such as a cpio
> or ar archive.  The main point is that by logically separating the parts
> of the data, it's easier to deal with it and it allows a more flexible
> system.

Besides, creating too much files would probably make DNLC and inode
cache useless.

-- 
 .-.   .-.    Life is a sexually transmitted disease.
(_  \ /  _)
     |        dave@srce.hr
     |        dave@fly.cc.fer.hr