On Tue, 12 Sep 2006 13:21:01 +0100 (BST), "David Carter" <dpc22@xxxxxxxxx> said: > On Sun, 10 Sep 2006, Wesley Craig wrote: > > > My solution (such as it is) was to reduce the wasteful amount of space > > sync_server was allocating per message: > > [...] > > The times-5 is completely gratuitous. In fact the pre-allocation of any > > memory for paths is wasteful, but I was not up for reengineering the memory > > scheme in sync_server at the time. > > This started out life as: > > sprintf(tmp, "%lu.", l->count); > result->msg_path = xmalloc(l->stage_dir_len+strlen(tmp)+2); > > At around 35 bytes a shot, you get rather more of these to the MByte. > > If I recall correctly, the "5 * (MAX_MAILBOX_PATH+1)" was put in to > support partitions. A lookup table for partitions and two integers (one > for the partition number, one of the message number on that partition) > should be all that is needed to reconstruct the paths at a later date. "rather more" still feels a little dangerous to me. sync_client is basically shoving an unlimited number of messages down the wire at sync_server without even once checking that sync_server is still a happy camper (other than the connection dropping out completely) The only problem I see with cutting the UPLOAD after 'n' messages and restarting it is that the folder on the replica will be in an intermediate state with UIDNEXT set quite high but a bunch of messages not there yet. On the flip side, if it keeps failing then the folder on the replica side contains no messages at all, which is somewhat worse in a failure situation where you actually need to cut over to the replica. Bron. -- Bron Gondwana brong@xxxxxxxxxxx ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
