On Tue, 2006-01-03 at 07:52 -0600, Les Mikesell wrote: > On Tue, 2006-01-03 at 02:35, Hans Kristian Rosbach wrote: > > > > > > There's always backup/mkfs/restore. If you aren't prepared > > > to restore you should probably take care of that before > > > worrying about efficiency. > > > > Do you know how long time it would take to put back 800GB of > > mailboxes on our mailserver from the tape backup? > > No customers in the world would allow us to actually take > > such a time-off from serving their mail. > > How do you plan to deal with an operator or software error > that erases your current files? That has nothing to do with the current discussion. But that would of course result in data loss and downtime while data is recovered from backup. Both covered by the contract agreement. > > Granted we COULD set up another box with a 1TB raid5 array > > to hold the data temporarily, but it would still take time > > since we would still have to shut down mail services before > > taking a copy. It would still be a bad workaround for a > > real problem. (Yes I know that ~99% of us don't ever need it) > > You can do a swap like this with very little downtime if > you do an rsync while the system is live to get most of > the data copied, the repeat the rsync with the --delete > option to catch any subsequent changes with the system > offline, then swap mountpoints. Yes, and this is soo much easier than running a program at night. > > Thus we would need an on-line defragmenter that we could > > set up for a low-prio night run once or twice a year. > > If you use maildir or other 1-message-per-file format, > a defragmenter isn't going to help much because it > won't know to move the directory contents together. > If you have standard mbox format you just have to > re-write them periodically which will happen anyway > if the users ever delete anything. mbox. pop3 users are usually ok, imap on the other hand =/ And the database holding userdata and statistics still won't often get such relief. -HK PS: I am fully aware of the possible workarounds, and do exercise them when needed. The point here is that there is indeed a need for an online defragmenter.
