Does anyone allow unlimited or extremely large quotas?

[Bron Gondwana]

On Mon, Nov 22, 2010 at 11:03:15AM +0100, Sébastien Michel wrote:
> > To be honest - it doesn't actually hurt too badly once it's in memory
> > > cache.  The cyrus.cache file isn't generally needed to be entirely
> > > read, and the secret of mmap is that you only read the bits you need
> > > as you need them - it's lazily loaded.
> >
> > I am fully agree with you. But I don't know what Cyrus really reads on
> SELECT to fulfill the mailbox structure.
> Since strace doesn't help to see what mmap reads on SELECT, so I made a test
> on NFS server.

Ooops.  I think the NFS server might be the problem here.
 
> With a 7MB's mailbox that contains 250 emails. cyrus.index is about 20KB and
> cyrus.cache is about 350KB.
> - on SELECT, nfsstat shows 15 NFS READ => 480KB on-the-wire NFS READ. It
> seems that both cyrus.cache and cyrus.index are read

What version of Cyrus are you testing with here?

> - on CLOSE, nfsstat shows 19 NFS WRITE and strace shows that both files are
> rewritten

You have got to be kidding me.  Unless there's actually something which
requires the files to be rewritten (i.e. an expunge event) then this
should not happen.  Again, Cyrus 2.4.x will be much more efficient in
this regard, only rewriting if you have explicitly enable immediate
expunge rather than "default" expunge.

> With a 6GB's mailbox that contains almost 100.000 emails. cyrus.index is
> about 8MB and cyrus.cache is about 120MB
> - on SELECT nfsstat shows 300 NFS READ => 9600KB on-the-wire NFS READ. OK it
> is less that the size of cyrus.index and cyrus.cache
> - on CLOSE nfsstat shows 4105 NFS READ and 4144 NFS WRITE => 2x130MB
> on-the-wire NFS.
> 
> In such situation mmap doesn't help because everything is read and write. I
> hope this behaviour can be optimized.

So don't use NFS.

As for read vs write.  Hmm... might be more possible with Cyrus 2.4 to
do this, but it's still going to be a fair bit of code complexity.  I
do agree with the underlying principle of "don't request more access
than you actually need" - but the added code complexity has to be
worthwhile too.

Bron.