Re: [PATCH] Mail fetching on memory-poor machines

[Jim Pick <jim@jimpick.com>]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Jim Pick <jim@jimpick.com>  on Wed, 14 Jul 1999
> | Why not fix the problem?  The results of the problem are so bad that
> | it's basically a bug.  Fixing it seems like a more logical thing to
> | do, rather than force everybody to use the program in a certain way.
> 
> Because, if I understand what your code does (which might not be the case),
> it only works for people who use Gnus "your" way while slowing it down
> unnecessarilly for those who are not on memory-starved systems, have large
> nnfolders, and do use Gnus to split mail sources.

I know.  I stated that the patch wasn't for everybody when I posted
it!

It wouldn't be too hard to put in a customize option to enable/disable
it - but I haven't gotten any feedback on whether this is wanted.  The
patch was ugly enough that I'm not sure that if it should be
integrated as is.

I can think of several different ways of achieving a similar effect.
For example, it might make sense for Gnus to track the size of the
buffers currently in use, and only save the least-recently-used ones
to disk to free up some space.  That's overkill for my case though.

I didn't put a lot of effort into it because Lars might want to do it
some other way.  The patch was just posted to illuminate the problem
(hopefully).

I'll live if the problem isn't fixed upstream - but I fixed it here,
so I thought I'd share.
 
> Personally, I am all for lean and mean, which is one of the reasons why I
> don't use nnfolder.  I tried it, briefly, back when I was on a 12MB system.
> That was a mistake :).

I still like nnfolder.  I don't find it very objectionable at all
(with my patch).

> For what its worth, inode starvation is not as likely as you might think.
> The average mail message is ~3-4kB; the average inode size on a modern
> filesystem is 4kB.  One message, one inode.  On an ~1GB filesystem you will
> have around 256k inodes (more, actually).  In practical terms, you will run
> out of space before you run out of inodes, unless your filesystem is tuned
> with unusually large inodes or you are suffering under a woefully
> restrictive inode quota.

My primary objection to nnml is primarily that it is painful to do
anything that scans the disk.  I've got a very large mail archive.

As an aside - I did manage to run out of inodes once when I was using
nnml before.  I compressed my mail files, and was using jka-compr.
When the files are compressed, they average out to be smaller than
than default 4kB per inode, and it suddenly becomes possible to run
out of inodes.  In that case, I just backed everything up, and
reformatted the partition with more inodes though.  No big deal.

Cheers,

 - Jim