home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / ultrix / 5992 < prev    next >
Encoding:
Internet Message Format  |  1992-07-31  |  1.7 KB
  1. Path: sparky!uunet!mcsun!uknet!cam-cl!cam-cl!maj
  2. From: maj@cl.cam.ac.uk (Martyn Johnson)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: Re: what are some good params for dumping to an exabyte?
  5. Message-ID: <1992Jul31.120859.13691@cl.cam.ac.uk>
  6. Date: 31 Jul 92 12:08:59 GMT
  7. References: <1992Jul31.062912.18701@news.clarkson.edu>
  8. Sender: news@cl.cam.ac.uk (The news facility)
  9. Reply-To: maj@cl.cam.ac.uk (Martyn Johnson)
  10. Organization: U of Cambridge Computer Lab, UK
  11. Lines: 28
  12.  
  13. In article <1992Jul31.062912.18701@news.clarkson.edu>,
  14. abstine@hobbes.erc.clarkson.edu (Art Stine) writes:
  15. |> Can anyone tell me what some good parameters are for dumping to an
  16. |> exabyte (2.3G and 5.0G) drive in order to get the most out of a tape?
  17.  
  18. This question often comes up. It seems to me that trying to find
  19. parameters which correctly express the size of an Exabyte is a waste
  20. of time, for two reasons:
  21.  
  22. 1. You don't usually want to split dumps across Exabytes, because they
  23.    are big relative to most filesystems.  More often you are doing the
  24.    converse - multiple dumps on one tape. In that case, dump's notion
  25.    of tape size is flawed.
  26.  
  27. 2. The code in dump which estimates what will fit on a tape is a historical
  28.    relic. In Ultrix, it will detect end of media and request a new tape
  29.    anyway. No need to tell it.
  30.  
  31. I wish there was an option to tell dump to forget about guessing the
  32. tape length (and that it were the default!).  In the absence of this, we
  33. just give it numbers which are so big that any dump we do will never be
  34. artificially split by dump. Just give it big numbers - we use "s 150000"
  35. and let the other default. Just watch out that you don't make the numbers
  36. so big that you get overflow!
  37.  
  38. Martyn Johnson      maj@cl.cam.ac.uk
  39. University of Cambridge Computer Lab
  40. Cambridge UK
  41.