dovecot - Jun 2009 - Quota over NFS with inode limit

I tried searching this list, but couldn't find anything related to  
inode limits except for linux quotas.

I wanted to add sieve support for our users, so was attempting to get  
our email system to use dovecot's deliver lda to handle email, instead  
of postfix's virtual lda, using maildir mailstore.

When I did this, I noticed that emails would get stuck in the queue if  
a user was over quota, this got fixed when I added in quota support,  
and set it up to check it using the line:

quota = fs:User quota:user:inode_per_mail

Now if a user excedes disk space via quota, it's bounced with a message.
But if a user excedes their inode quota, it's still tempfail and hangs  
in the queue till it expires.

I just wanted to know if anyone knows about this issue, if I made a  
stupid mistake or anything else, before I go digging into the source.

Looking into this some more, all the log entries that cause this have  
to do with rename and EFBIG.

deliver(xxx):  
rename(/var/mail/virtual/xxx/tmp/1244513712.M557487P17017.5011.mail,  
/var/mail/virtual/xxx/new/1244513712.M557487P17017.5011.mail,W=2019)  
failed: File too large

I do see other accounts that are at/over quota for blocksize and  
inodes, and they are all failing on open or fsync with DIsk quota  
exceeded (EDQUOT I assume)


Quoting Patrick Domack <patrickdk at patrickdk.com>:
> I tried searching this list, but couldn't find anything related to
> inode limits except for linux quotas.
>
> I wanted to add sieve support for our users, so was attempting to get
> our email system to use dovecot's deliver lda to handle email, instead
> of postfix's virtual lda, using maildir mailstore.
>
> When I did this, I noticed that emails would get stuck in the queue if
> a user was over quota, this got fixed when I added in quota support,
> and set it up to check it using the line:
>
> quota = fs:User quota:user:inode_per_mail
>
> Now if a user excedes disk space via quota, it's bounced with a
message.
> But if a user excedes their inode quota, it's still tempfail and hangs
> in the queue till it expires.
>
> I just wanted to know if anyone knows about this issue, if I made a
> stupid mistake or anything else, before I go digging into the source.

On Jun 10, 2009, at 1:51 PM, Patrick Domack wrote:
> Looking into this some more, all the log entries that cause this  
> have to do with rename and EFBIG.
>
> deliver(xxx): rename(/var/mail/virtual/xxx/tmp/ 
> 1244513712.M557487P17017.5011.mail, /var/mail/virtual/xxx/new/ 
> 1244513712.M557487P17017.5011.mail,W=2019) failed: File too large
That looks weird. So this is with Linux as NFS client? What do you use  
as NFS server? To me this feels like NFS server bug..