Date: Tue, 03 Mar 1998 21:23:10 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Karl Denninger <karl@mcs.net> Cc: Wilko Bulte <wilko@yedi.iaf.nl>, sbabkin@dcn.att.com, tlambert@primenet.com, jdn@acp.qiv.com, blkirk@float.eli.net, hackers@FreeBSD.ORG, grog@lemis.com Subject: Re: SCSI Bus redundancy... Message-ID: <XFMail.980303212310.shimon@simon-shapiro.org> In-Reply-To: <19980303200652.07366@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Mar-98 Karl Denninger wrote:
...
> If the filesystem has news on it? Forget it. The small files blast
the
> hell out of restore (or pax, or anything else) during the creates - even
> if
> mounted async during that operation. It simply takes forever. I've
> tried
> copying a 4G news spool disk before - get ready for a 12 hour wait.
I always thought news is an excellent candidate for a heavily cached RAID-0.
8 stripes or better. Some of my customers insist on RAID-5 which is very
slow on WRITE. Never understood why. I figured out, whith 8 stripes on a
RAID-0, you will fail /var/spool/news aboutevery 18 months.
...
> Databases on Unix filesystems aren't safe. Neither are databases on raw
> partitions. I've seen both lost due to physical problems. Ever see a
> disk
> adapter decide to "translate" a block address? I have - and guess what
> happened to the database (this one was on a raw partition)? It was
> over a week later before the problem was detected when the back-end
> crashed
> for no ascertainable reason, and the validate failed. That one wasn't my
> responsibility, and the person who *WAS* the DBA wasn't doing the right
> things with the TLOGs.
Failures will occur, but if a database is on ``raw disk'' which is
RAID-{1,5} on a relaible adapter, you will not have much to complain about.
What I am nervous about, is running RAID-{1,5} in the Unix kernel. It
makes the actualy integrity of your disks dependant on the sound driver,
the VGA driver, X11, PPP, etc. Any bug in these not only will lay your
filesystem to rest. It will take the ``disk'' with it. Then I have yet to
see an in-kernel RAID that can truely recover concurrently with the O/S
operation. I am not talking perfromance, I am taking functionality at all.
...
>> 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.
>
> To a point this is true. The problem is that the smaller disks rotate
> slower, and have bit densities that are lower.
Yup. This is where you see a benchmark machine using 200 4 GB drives for a
database of 50GB. Nobody can affrd such machine, but benchmarks being what
they are.
> There is a tradeoff between seek latency and transfer time. If there are
> lots of small files, the huge number of small disks wins big. If there
> are
> a few large files, the small number of disks with speed on the physical
> I/O
> wins, provided you can seek sequentially.
Yes, but they all end up on a SCSI bus. The great equalizer. At least I
do not feel so lonely in my views any more :-)
Simon
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980303212310.shimon>