Xref: utzoo comp.unix.wizards:25502 comp.periphs.scsi:2561
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!elroy.jpl.nasa.gov!ncar!csn!boulder!alumni.colorado.edu!rlr
From: rlr@alumni.colorado.edu (Roger Rose)
Newsgroups: comp.unix.wizards,comp.periphs.scsi
Subject: Re: My Exabyte has a personality! It hates cp! HELP!!
Message-ID: <1991May9.153449.1827@colorado.edu>
Date: 9 May 91 15:34:49 GMT
References: <1991May2.044713.12583@coplex.uucp> <714@adpplz.UUCP>
Sender: news@colorado.edu (The Daily Planet)
Organization: University of Colorado, Boulder
Lines: 30
Nntp-Posting-Host: alumni.colorado.edu


> martin@adpplz.UUCP (Martin Golding) writes:
>
> The exabyte is (internally) fixed very large block. Filemarks are only
> found between blocks. When you cp the file onto the exabyte, somebody
> somewhere is giving you padding for the last block. When you read it
> back, you get the padding ABSOLUTELY FREE!. You would find the same
> effect on a cartridge tape, but not quite as much extra data (512).

Almost right.  The Exabyte's do use a fixed blocksize on tape; however,
they automatically map other blocksizes into these.  As far as things
look to the computer, the drive can function as either a fixed or a
variable-block device.  (Also note that on the 2.3Gb model there is are
significant capacity and speed penalties for blocks that aren't an even
multiple of 1024 bytes.)

The underlying cause of the garbage data is most likely in the device
driver's handling of the last block of data.  As far as the Exabyte
drive is concerned, it would be perfectly acceptable to write a short
block at that (or any other) point.

Handling a short block when reading the file is trivial for
variable-block mode; however, a bit difficult to do *portably* for
fixed-block mode.  (The SCSI spec leaves a bit much unstated on
fixed-block transfers, so it would probably be necessary to
special-case the device driver for various vendors' tape devices.)

-- 

Roger Rose  {rlr@boulder.colorado.edu}