home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / ultrix / 9549 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.2 KB
  1. Path: sparky!uunet!tis.com!mjr
  2. From: mjr@tis.com (Marcus J Ranum)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: Re: Recommendations for high disk throughput
  5. Date: 28 Jan 1993 15:37:27 GMT
  6. Organization: Trusted Information Systems, Inc.
  7. Lines: 36
  8. Message-ID: <1k8ujnINNcsl@sol.tis.com>
  9. References: <1993Jan27.205507.13234@grc.genroco.com> <1k7la9INNk6c@sol.tis.com> <2001@niktow.canisius.edu>
  10. NNTP-Posting-Host: sol.tis.com
  11.  
  12. pavlov@niktow.canisius.edu (Greg Pavlov) writes:
  13. >> for database or other applications like imaging than it will
  14. >> be for NFS. ..... 
  15. >
  16. >  Imaging, maybe, but I see this statement made a lot re databases and I
  17. >  don't understand it.  "Database" does not equate with large sequential 
  18. >  reads; in some cases it does, in some cases it doesn't, there just ain't
  19. >  no generalization since databases span much of the applications spectrum.
  20.  
  21.     Yeah, good point. I guess my remark was colored from back when
  22. I used to have to watch bulk unloads and loads run for hours and hours.
  23. Perhaps the reason it was so slow was because the data was scattered
  24. all over the disk. I guess it's implementation dependent, but I'd
  25. *hope* that a database would try to cluster related tables or tuples
  26. within close blocks. Admittedly, if your dbms goes through the filesystem
  27. all bets are somewhat off, though the BSD filesystem might not make
  28. this totally agonising. Stuff that uses the raw partition *should*
  29. take advantage of these things. They probably don't though.
  30.  
  31.     Remember what dbms' were like when they worked through the
  32. filesystem, when it used the old v7 block allocation stuff that
  33. put data all over the disk using a "fifty-two pick up" algorithm?
  34. Sorry. Hope I didn't ruin your appetite.
  35.  
  36.     Greg's remarks about using stripe sets for dbms applications
  37. is certainly more accurate than mine. :) In just about any given high
  38. I/O situation a stripe set of {small|fast|cheap} disks with as many
  39. controllers as possible is a Good Thing Indeed. When I was at DEC
  40. a buddy of mine did a pretty frighteningly fast demo using a stripe
  41. set of Rz57s. Update times were small. Track caches are a nice thing. ;)
  42. What happens to your database when one of the drives flames out is
  43. left as an exercise to the reader. :)
  44.  
  45. mjr.
  46. -- 
  47.                                                  "guns don't die. people do."
  48.