Attila Nagy
2011-Jun-09 18:56 UTC
[Dovecot] 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,
Timo Sirainen
2011-Jun-13 13:40 UTC
[Dovecot] Converting CLIENT_MAIL_DATA_MAX_INMEMORY_SIZE to a configurable?
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?