home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / ultrix / 6590 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.1 KB  |  49 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!decwrl!deccrl!news.crl.dec.com!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alan
  3. From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  4. Subject: Re: 2Gig Rule??
  5. Message-ID: <1992Aug31.182440.3845@nntpd2.cxo.dec.com>
  6. Lines: 36
  7. Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  8. Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  9. Organization: Digital Equipment Corporation
  10. References:  <1992Aug30.055157.1084@crc.ricoh.com>
  11. Date: Mon, 31 Aug 1992 18:24:40 GMT
  12.  
  13.  
  14. In article <1992Aug30.055157.1084@crc.ricoh.com>, shahryar@crc.ricoh.com (Shahryar G. Hashemi) writes:
  15. >
  16. > [ The customer asks for details about support of the Exabyte 8500. ]
  17.  
  18. This is what I know.  First consider the source of the 2 GB limitation.
  19. Tape drives are devices.  All devices are files.  The current BYTE
  20. offset within a given file is stored as a 32 bit signed integer.  If
  21. the byte offset ever exceeds the capacity allowed by this 32 bit signed
  22. integer some form of ENOSPC error is usually the result.
  23.  
  24. As a result you're limited to 2 GB per file/device.  I've never used
  25. one of these, but I would think that if you could management not to
  26. get an ENOSPC error up near the 2 GB range, you could put 2nd 2 GB
  27. file on the media.  The problem is that applications that write tapes
  28. will probably die or want to restart if they ever get an ENOSPC error.
  29.  
  30. Solution?  The SCSI CAM driver available with V4.2 has a way of
  31. presenting a suitable lie to the file layer about the byte offset
  32. for large tapes.  The result is that applications won't see these
  33. errors until you really do reach the end of the media.  I believe
  34. that some version of dump has been modified to know this is going
  35. on.  I believe the V4.3 dump(8) will have this feature.
  36. >
  37. >Shahryar
  38. >
  39. >--
  40. >Shahryar G. Hashemi
  41. >System/Network Administrator -- RICOH Corporation California Research Center
  42. >2882 Sand Hill Road, Suite 115         Telephone: (415) 496-5730
  43. >Menlo Park, CA  94025-7022             FAX: (415) 854-8740
  44. >E-Mail: <shahryar@crc.ricoh.com>
  45. >
  46. --
  47. Alan Rollow                alan@nabeth.cxo.dec.com
  48.  
  49.