home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / ultrix / 9545 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  1.6 KB
  1. Path: sparky!uunet!ukma!cs.widener.edu!dsinc!ub!niktow!pavlov
  2. From: pavlov@niktow.canisius.edu (Greg Pavlov)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: Re: Recommendations for high disk throughput
  5. Message-ID: <2001@niktow.canisius.edu>
  6. Date: 28 Jan 93 10:32:54 GMT
  7. References: <C1BFFz.EEr@news.iastate.edu> <1993Jan27.205507.13234@grc.genroco.com> <1k7la9INNk6c@sol.tis.com>
  8. Organization: Canisius College, Buffalo NY. 14208
  9. Lines: 24
  10.  
  11. In article <1k7la9INNk6c@sol.tis.com>, mjr@tis.com (Marcus J Ranum) writes:
  12. >
  13. > IPI's going to be a lot better
  14. > for database or other applications like imaging than it will
  15. > be for NFS. ..... 
  16.  
  17.   Imaging, maybe, but I see this statement made a lot re databases and I
  18.   don't understand it.  "Database" does not equate with large sequential 
  19.   reads; in some cases it does, in some cases it doesn't, there just ain't
  20.   no generalization since databases span much of the applications spectrum.
  21.  
  22.   Actually, I would say that a lot of people spend a lot of time to cleverly
  23.   construct databases and software to reduce sequential data traversal to a
  24.   minimum, or eliminate it altogether.  In the situations where this can be
  25.   done (and I would guess that in the majority of applications, it is the
  26.   correct and most useful strategy), and where there is a lot of user activity,
  27.   I would want to spread the data out among as many controllers and under as 
  28.   many read/write heads as I could - to the extent that the cpu and systems 
  29.   software can handle it.  Cheaper, smaller disks, but more of them, would
  30.   then seem to be the more appropriate choice.
  31.  
  32.  
  33.   greg pavlov
  34.   pavlov@fstrf.org
  35.