Re: [exim] Exim, Dovecot, mdir and hardlinks - a true story

Top Page
Delete this message
Reply to this message
Author: Cyborg
Date:  
To: exim-users
Subject: Re: [exim] Exim, Dovecot, mdir and hardlinks - a true story
Am 14.08.19 um 18:24 schrieb Phil Pennock via Exim-users:
> On 2019-08-14 at 12:54 +0100, Jeremy Harris via Exim-users wrote:
>> Do we need a fast/poor quota method for cases where the size-file
>> cannot be used?
> Just to raise the possibility to see if others can spot approaches which
> make this feasible rather than a giant can of worms: direct support for
> filesystem quotas in Exim, using soft limits set to match Dovecot's.
>
> Caveat in all of this: I've never played with quotas from the C APIs, so
> don't know enough to speak authoritatively here; this is based on some
> quick man-page and source checks, to write this email.
>
> That should be a "proper" solution, which is lightweight in use, if
> folks already have the FS quotas turned on. Which my uninformed guess
> is "yes, because that's the sanest way for Dovecot to implement quotas
> with hard link support".
>


I really believe, an option to match quota/du behaviour and use stat()
on each file to check
the inode, is fine. A) it's relatively simple to do, B) does not break
existing installations and C) works on NFS as well, i think.

>From a mailhosters reallive experience, i can tell, that we had to

switch from local diskstorage to a nfs storage for a customer over night,
as he ran out of diskspace and needed way more we could have available
on the local storage. So a solution that works in both situations
is handy. The local and the nfs share had both SSDs in use, so the
stat() call would be no big deal, even on very big mailboxes IMHO.
And, as NFS means local network, you get a latency in the process anyway
and everyone is happy with it, due to available space is the main issue
for mailboxes these days. Noone cares if it takes a few ms longer to
access it. They only ask how much GB they can get per Euro.

best regards,
Marius