On 04-Mar-98 Karl Denninger wrote:
> My CMD RAID adapters have saved my nuts twice in the last month.
> In both cases there was a non-recoverable, hard sector error on a 9G
> Without parity I would have lost something. With the RAID5 in place I
> nothing, other than the time to pull the pack, replace it, and set the
> disk to "warm spare" (the system had already started the rebuild onto the
> existing spare).
This is what a RAID controller should do. Any less, junk it.
> Lose 36GB all the way back to your last full + incremental dump (at least
> day's worth of revisions) across 10,000 customers and tell me what
> to your head when they get done with you.
This is a small database. I had to deal with customers with 3,000 drives
per system and was told there are larger.
> The problem isn't even necessarily the data loss - its the restore time.
> 9G drive takes a shitload of time to reload from even the fastest DLT
> We still run tapes nightly for incrementals, and weekly for full dumps -
> they are more for the "aw shit" user-induced stupidity (like the infamous
> "rm -rf *") rather than hardware coverage. The pain of a restore across
> disks of this size is just too darn big.
I wrote a white paper at Oracle some years ago, claiming that databases
over a certain size simply cannot be backed up. I became very UN-popular
very quickly. In you moderate setup, you already see the proof of
This is why most MIS types shiver when they hear about databases on Unix
filesystems. All you need is a crash and fsck in a bad mood. If you are
lucky, the entire data base is gone. If you are unlucky, a block will
disappear form somewhere in the middle, and you will find out a week later.
Now backup is literally useless.
> This is, by the way, one of the reasons I used to favor lots of 1G drives
> and filesystems - they can be restored in an hour or so if one fails.
> a 9G drive, even the newest and fastest ones, and the best tape devices,
> you're looking at a multi-hour outage.
True. Your perfromance also goes up with the smaller drives. You can
stripe better. I think I mentioned it before in this forum; Most DBMS
benchmarks only use 300MB of the disk. This is sort of the ``sweet spot''
between system cost and perfrormance.
Shimon@Simon-Shapiro.ORG Voice: 503.799.2313
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message