🚀 go-pugleaf

pavlov@niktow.canisius.edu (Greg Pavlov) writes:
>> for database or other applications like imaging than it will
>> be for NFS. ..... 
>
>  Imaging, maybe, but I see this statement made a lot re databases and I
>  don't understand it.  "Database" does not equate with large sequential 
>  reads; in some cases it does, in some cases it doesn't, there just ain't
>  no generalization since databases span much of the applications spectrum.

	Yeah, good point. I guess my remark was colored from back when
I used to have to watch bulk unloads and loads run for hours and hours.
Perhaps the reason it was so slow was because the data was scattered
all over the disk. I guess it's implementation dependent, but I'd
*hope* that a database would try to cluster related tables or tuples
within close blocks. Admittedly, if your dbms goes through the filesystem
all bets are somewhat off, though the BSD filesystem might not make
this totally agonising. Stuff that uses the raw partition *should*
take advantage of these things. They probably don't though.

	Remember what dbms' were like when they worked through the
filesystem, when it used the old v7 block allocation stuff that
put data all over the disk using a "fifty-two pick up" algorithm?
Sorry. Hope I didn't ruin your appetite.

	Greg's remarks about using stripe sets for dbms applications
is certainly more accurate than mine. :) In just about any given high
I/O situation a stripe set of {small|fast|cheap} disks with as many
controllers as possible is a Good Thing Indeed. When I was at DEC
a buddy of mine did a pretty frighteningly fast demo using a stripe
set of Rz57s. Update times were small. Track caches are a nice thing. ;)
What happens to your database when one of the drives flames out is
left as an exercise to the reader. :)

mjr.
-- 
                                                 "guns don't die. people do."