Bron Gondwana wrote: >> 1. It would be nice from a provisioning standpoint to be able to enumerate >> available partitions and their capacities within the IMAP protocol itself. >> This >> way, provisioning scripts could decide intelligently which backend and >> partition >> to use without resorting to SNMP or SSH or other. Is this something that >> could >> be delivered in an annotation or "ID" response perhaps? > > Some of the work Ken did with this (auto-choose-partition) would probably be > extendable. I like the idea.
Was this the discussion about the autocreate patch in the last few months? Do you have any more info about this? >> How about setting a server shutdown or motd message that applies only to a >> particular partition? We've had cases where we had to restore a whole >> partition >> after some SAN buggery. It would have been nice if we could have locked out >> or >> at least provided a message directly to the affected users. > > Hmm... interesting. Would you do this via the user's INBOX partition? That's what I was thinking. Shared folders on an affected partition are a case I haven't considered. Managing it with cyradm would be something like: > setinfo --partition XX shutdown "Server having problems. Check back later." > Now, you see - this is why we just run separate instances on the same machine > rather > than using partitions at Fastmail - you get all this for free, and besides > you can > have the replicas go different places. That sounds like a work-around for inadequacies in what can be done with partitions :) >> Somewhat orthogonally, what about being able to configure separate >> metapartitions per metadata type for a partition? For example, as you >> mention on >> #5 on your list, one metapartition to put the cyrus.index files on a fast SSD >> and another to put the large squatter files on cheaper, slower storage? > > Yeah, this and database file locations even more so. It would be great to > have > the statuscache and deliver dbs on tmpfs or similar to avoid the disk IO. Yes, that would be nice. >> 4. If you're going to be computing SHA1s for messages anyway, would there be >> any >> value in hashing the message files across sub-directories, so that >> directories >> wouldn't get to be so large? ... > > Ick. You could hash by UID just as easily really, least-significant bit(s). > I saw the response to this - anything that doesn't let you open by explicit > filename quickly will suck. See, our backup software reads the cyrus.index > to choose which files to back up as well - so we never[tm] enumerate the > directory. Except for reconstruct of course. My biggest complaint is having to wait for 'ls' when I am looking at a directory. I realized after sending this that my problem is really that GNU ls is sorting the results by default and if I change it to unsorted than it responds much more quickly. >> 5. What about toggling whatever CYRUS_VERBOSE enables by sending a signal or >> something like that? On my test systems I have gotten some good info from >> that >> which I would not have otherwise gotten but it is not feasible to enable it >> on >> my production systems. > > Hey, that's a cool idea. Pretty easy too. Great to hear it! Maybe I should try it... >> 6. sieveshell: Command to report supported extensions (a little more >> intuitive >> than 'nc localhost sieve'). > > Sounds great. Yeah, also probably pretty trivial, I'd guess. >> 7. Doc additions: (I could do some of these, if I'd make the time...) There >> are >> some cyradm commands that, in a Murder setup, need to be run from a >> front-end or >> back-end (sometimes a particular back-end). For example, it took me a while >> to >> figure out that 'xfer' needs to be run from the source back-end and not from >> a >> front-end. (Maybe that is a feature request itself?) For some of the >> maintenance >> utilities that check and modify the spools or config data, it's not always >> clear >> if they can be run with the server live or if it should be shut down, such as >> 'ctl_cyrusdb -r' or 'quota -f'. > > Yeah, it would be fantastic if you can do some of these - particularly the > ones > that I don't use myself or understand particularly well. Good docs are very > important for a polished product :) Yeah, another area should I should probably put-up or shut up ;) >> 8. Last one, I promise: lmtpproxyd to use local mupdate instead of having to >> hit >> the master. Maybe this has changed? I don't see it mentioned in the change >> log. > > Don't have a clue sorry. > > It would be fantastic if you could put these ideas on the wiki. I'd be > tempted > to say "put items in Bugzilla", but honestly it's a bit of a jungle in there > at > the moment! Maybe both, and cross link to the bug IDs from the wiki. Sure, I can put them in both and perhaps expand on them a little more (use-cases for example). Thanks! Wil
signature.asc
Description: OpenPGP digital signature
---- 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
