dovecot - Jun 2011 - Converting CLIENT_MAIL_DATA_MAX_INMEMORY_SIZE to a configurable?

Hi,

Currently Dovecot's LMTPd writes incoming emails to mail_temp_dir if 
it's bigger than 128k. But I would like to spare those unnecessary 
operations (creating a file, deleting it, writing into it, reading from 
it, checking whether there is free space and if not, rejecting 
(temporarily) the message). Memory is cheap, disk IO is not. :)
And BTW, on a lot of systems, /tmp is a memory file system already, so 
there is absolute no need for this.

I only fired two greps so far before writing this mail, in the hope that 
I can spare writing, testing and sending a patch, which will be either 
rejected, or rewritten. :)

So, am I right that the following constant would be needed to be 
converted into a configurable setting and the task is done?
static int
client_input_add(struct client *client, const unsigned char *data, 
size_t size)
{
         if (client->state.mail_data->used + size <            
CLIENT_MAIL_DATA_MAX_INMEMORY_SIZE &&
             client->state.mail_data_output == NULL) {
                 buffer_append(client->state.mail_data, data, size);
                 return 0;
         } else {
                 return client_input_add_file(client, data, size);
         }
}

It could be defaulted to 128k, but the user could set it "unlimited"
(0
or -1, depending on the author's mood, 0 and/or -1 being unlimited, or 0 
being 0, meaning don't even store a bit -doesn't really make sense to
me).
LMTP is mostly protected from the outside world, so I don't see too much 
DoS potential here (absolutely not more than in the tmpfs case).

Thanks,

On Thu, 2011-06-09 at 20:56 +0200, Attila Nagy wrote:
> Hi,
> 
> Currently Dovecot's LMTPd writes incoming emails to mail_temp_dir if 
> it's bigger than 128k. But I would like to spare those unnecessary 
> operations (creating a file, deleting it, writing into it, reading from 
> it, checking whether there is free space and if not, rejecting 
> (temporarily) the message). Memory is cheap, disk IO is not. :)
> And BTW, on a lot of systems, /tmp is a memory file system already, so 
> there is absolute no need for this.
If there's not enough disk space, nowadays the message is read fully
into memory instead of tempfailing.

Also are you sure that writing to the file actually produces disk I/O?
Even if /tmp isn't a memory filesystem, I think there's a good chance
that the file will be gone before any disk writes have a chance to
start. Can you see some measurable disk I/O change by changing this
value?