home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sgi / 16806 < prev    next >
Encoding:
Internet Message Format  |  1992-11-24  |  2.3 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu!olivea!sgigate!odin!twilight!zuni!anchor!olson
  2. From: olson@anchor.esd.sgi.com (Dave Olson)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Getting the full 2.0 Gb from DAT's
  5. Message-ID: <soat894@zuni.esd.sgi.com>
  6. Date: 24 Nov 92 02:17:51 GMT
  7. References: <1992Nov20.182144.728@nsisrv.gsfc.nasa.gov> <skdn1k0@zuni.esd.sgi.com> <1992Nov23.232212.3184@odin.corp.sgi.com>
  8. Sender: news@zuni.esd.sgi.com (Net News)
  9. Organization: Silicon Graphics, Inc.  Mountain View, CA
  10. Lines: 32
  11.  
  12. In <1992Nov23.232212.3184@odin.corp.sgi.com> stanj@ferrari.corp.sgi.com (Stan Jensen) writes:
  13.  
  14. | In article <skdn1k0@zuni.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes:
  15. | |> In <1992Nov20.182144.728@nsisrv.gsfc.nasa.gov> markb@news.gsfc.nasa.gov (Mark R. Baith) writes:
  16. | |> | I understand that there is a DAT bug on SGI's that limits the total
  17. | |> | archive space to 1.2 Gb, even though you may be using a 90M or 
  18. | |> | 2.0 Gb tape. I understand that the magazine pipeline recently
  19. | |> | published a fix. Can someone pass the fix along? Thanks -M
  20. | |> 
  21. | |> There is no such bug.  All DAT drives that SGI has ever shipped
  22. | |> support the 90 meter tape.  There were earlier drives shipped by
  23. | |> Ardat (and other vendors) that did *not* support the longer tape,
  24. | |> because it didn't exist when the firmware was written.
  25. | |> 
  26. | |> I have never seen any such article in the Pipeline.  If it is there,
  27. | |> and is on this subject, it is wrong.
  28. | 
  29. | I think Mark heard about the "brutab" problem with DATs and if he sends me
  30. | his FAX number, I will send him pages 12&13 from the Sep/Oct issue (V3#5).
  31.  
  32. bru works fine (better!) if /etc/brutab is not used, or if everything
  33. therein is commented out.  In particular, the size field should always
  34. be absent, or set to 0.  I don't remember seeing that article, so I
  35. won't comment further on it.
  36.  
  37. In general, I would strongly recommend that people not use bru, since
  38. it isn't very portable, and uses more tape.  The fact that our own system
  39. backup and recovery mechanism uses bru does not change my recommendation.
  40. --
  41. Let no one tell me that silence gives consent,  |   Dave Olson
  42. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  43.     Maria Isabel Barreno                        |   olson@sgi.com
  44.