Implement Cyrus IMAPD in High Load Enviromment

[Vincent Fox]

Bron Gondwana wrote:
> I assume you mean 500 gigs!  We're switching from 300 to 500 on new
> filesystems because we have one business customer that's over 150Gb 
> now and we want to keep all their users on the one partition for
> folder sharing.  We don't do any murder though.
>
>   
Oops yes.  I meant 500 gigs.  The potential downside of
running an fsck on  terabyte+ filesystems is not worth
the risks IMO.  The tremendous speed & efficiency of
Cyrus is in it's small files and the indexes.  However you
have to keep that in mind when estimating not just backups
and other daily/weekly items but more serious items.

Really I've looked at fsck too many times in my life and
don't ever want to again.  Anyone who tells me "oh yes but
journalling solved all that long ago...." will get an earful
from me about how they haven't run a big enough setup
with enough stress on it to SEE real problems.  I have seen
both journalled Linux and logged Solaris filesystem turn up
with data corruption and ended up staring at that fsck
prompt wondering how many hours until it's done.....

The antiquated filesystems that 99% of admins tolerate and
work with every day should be lumped under some kind of
Geneva provision against torture.  It's a mystery to me why
it's not resolved years ago and why there isn't a big push
for it from anyone.

"It doesn't matter how fast it is, if it isn't CORRECT!" should
be some kind of mantra for a production data center but it
still seems majority of my colleagues talk same as in 1980s'
about how if we turn off this or that safety feature we can
make the filesystem faster.

OK stepping off my soapbox now.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3250 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20090928/d3b67694/attachment.bin