quota bug involving nested quota roots?

[Nik Conwell]

I'm running 2.3.8 (Invoca) and see strange quota behavior.  I checked the 
changelog for 2.3.12p1 and no mention of quota fixes (32-bit).  Unfortunately I 
don't have a 2.3.12p1 system to check this out.  Do people see similar things on 
the current version?  Am I doing something wrong having nested quotas this way?


My mailbox has quota and usage:

quota -f |grep -E "user/nik|Quota"

    Quota   % Used     Used Root
  10485760       15  1640288 user/nik


If I set a quota on user/nik/restore (empty mailbox) and do quota -f, my 
recorded usage changes:

sq user/nik/restore 1

quota -f|grep -E "user/nik|Quota"

    Quota   % Used     Used Root
  10485760       13  1442491 user/nik
        1        0        0 user/nik/restore


I did finds on the filesystem and added up file sizes:


full=`find /cyrus/master07/spool/n/user/nik -type f -ls|grep -v "cyrus\."|awk '{print $7}'|add`;echo "full=$full"

restore=`find /cyrus/master07/spool/n/user/nik/restore -type f -ls|grep -v "cyrus\."|awk '{print $7}'|add`;echo "restore=$restore"


full=1679655197
restore=0


The full / 1024 matches the original 1640288 used so the problem seems to be 
quota -f not correctly traversing when there is another lower quota root.

If I remove the user/nik/restore quota and do quota -f, the value matches the 
original again:

sq user/nik/restore remove 1

quota -f|grep -E "user/nik|Quota"
    Quota   % Used     Used Root
  10485760       15  1640288 user/nik


-nik
Nik Conwell
Office of Information Technology
nik at bu.edu