Timo Sirainen wrote:
Are these old files, or why don't they contain the ,S=1234 in filename? That would help a lot when recaculating Maildir++ quota.
Ah legacy reasons :) We used to use UFS (with quotas) inside zvol on the zfs server. But this panics, and has performance issues.
We changed to plain zfs (without quotas) and enabled soft-quotas/Maildir++. So yes, some mails are so old that they do not contain ,S=1234. All new mail does:
-rw------- 1 5091 mail 1676 Aug 26 12:31 1251257478.M554367P15043.vmx05.unix,S=1676,W=1711 -rw------- 1 5091 mail 1674 Aug 26 12:33 1251257579.M948723P22818.vmx04.unix,S=1674,W=1709
But Maildir++ quota is supposed to work without locks.. :)
Sure, but 20 processes all scanning the same directory, over 12 servers, is unpleasant. :)
Do you need Maildir++ quota at all? With v1.2 you could use dict quota with file backend. It'll use dovecot.index.cache when recalculating quota, although it doesn't do that unless the quota is lost for some reason (so about never).
We only needed a temporary solution. Long term, we have already tested ZFS's user-quota, and this is where we will go. Getting enough momentum to get the process started (management...) is what has been frustrating. Would you say this trouble is soft-quotas scanning, and not just generic index rebuild?
The reason I ask is that; if it is related to quotas, that gives me yet-another reason to move to zfs quotas (and the trouble will go away). If it is normal index rebuilding, it will still happen even after using ZFS quotas.
Thanks for your reply though,
Lund
-- Jorgen Lundman | lundman@lundman.net Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)