Re: [bug-mailutils] disk quotas and mbox append

[Stephen Bylo]

On Wed, 2004-01-14 at 00:15, Alain Magloire wrote:
> > 
> > Dear All,
> > 
> > I have a question about disk quotas.
> > How does mailutils/mbox deal with disk quotas?  Does anybody have any 
> > experience with them? Do they work well with Linux quotas on kernel 2.4
> > over *NFS* ?
> > 
> > I've looked through the mail archive and cannot find any infos about
> > this.  I've looked through the code a little but cannot pinpoint what
> > exactly happens when, say whilst appending a message to a mailbox, disk
> > space runs out due to quotas. Does the mailbox get corrected or
> > truncated in some expunge procedure?
> > If after writing to the mailbox you get the first "Disk quota exceeded" 
> > error at close() what is done about this?
> > 
> 
> Usually expunging means removing emails so you should endup having
> less email then before.
> 
> The expunge is done in steps:
> - copy the original mailbox to a temporary place, filtering out the mark for 
> deletion
> - truncate the original mailbox to the new size.
> - copy the temp back to the original.

yes thanx.  I did see that in the code and archive.

> 
> So if the truncate fails, the expunge() code bails out.
> Usually the truncate(), if it fails, will live the original file untouch  ... 
> in theory.
> 
> So the problem of quotas is when appending/saving emails to a new mailbox.
> It this case, you may have a problem.  The next write() may fail leaving
> things in a bad state.

Yes.  I have tested mailbox_append_message() and found that the mailbox
gets truncated, ie. a mail header can get cut in half when not being
able to write when over quota and using NFS!

The problem with writing over NFS is that the writes are delayed and the
results from these writes may come too late or at the latest at fsync()
and/or close().  This is why the return value from close() AND fsync()
must be evaluated so that the program can bail out and reverse the
append.  I don't think the code does this.

See this discussion on writes over NFS :
http://groups.google.com.sg/groups?hl=en&lr=&ie=UTF-8&threadm=3i2ol5%24n9h%40engnews2.Eng.Sun.COM&rnum=2&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D3i2ol5%2524n9h%2540engnews2.Eng.Sun.COM%26rnum%3D2
or
(
Subject: Re: Sun: "Silent" Data Lossage, NFS, etc.
Date: 17 Feb 1995 18:07:33 GMT
Organization: Sun
Message-ID: <address@hidden>
References: <address@hidden>
)

> 
> For "new" emails, this is rather done with sendmail or whatever MTA you have 
> on
> your system.  We do have a mail.local in mailutils, I did not check if can 
> handle
> the case where a next write() fails.

For delivery we are using qmail.  I have not yet tested if it works when
quotas are full.

What I have noticed with Linux quotas over NFS is that when I write chunks of 
data
to a file and my quota gets exceeded, there is one set of fwrite/fsync and 
fclose calls that DO
NOT return any errors!!!  Only in the next set of calls do I see a "Quota 
exceeded" error,
but this is too late - the data is already corrupt!!
Not even "cat" shows any errors.  I am doing further testing here.  I will also 
try to 
tune the NFS server (sync and no_wdelay options etc).

Thanxs
Steve