afleming@watsci.uwaterloo.ca (Allan Fleming) (07/27/90)
I am unable to read exabyte tapes that were written under OS 3.2 while using OS 3.3. All I get is a message from bru - warning end of volume one - while at the begining of the tape. I can read exabyte tapes written under OS 3.3 - Help, Allan Fleming
olson@anchor.esd.sgi.com (Dave Olson) (07/28/90)
In <1990Jul27.161034.6142@watserv1.waterloo.edu> afleming@watsci.uwaterloo.ca (Allan Fleming) writes: | I am unable to read exabyte tapes that were written under OS 3.2 | while using OS 3.3. All I get is a message from bru - warning end | of volume one - while at the begining of the tape. I can read exabyte | tapes written under OS 3.3 - Help, Allan Fleming This was a bug introduced into 3.3, and is one of the bugs fixed in the 'real' 3.3 (3.3.1) release that will actually ship to customers. The 3.3 release that some customers have received was shipped only to customers requiring it for new hardware, and in some cases at the discretion of sales offices for 'important' bug fixes. The work around is to read the tape with dd if=/dev/tape bs=1k | bru -vtf - ... and similarly for writing. Note that this is not the same block size that is set with -b, that is the blocking factor. The default block size for Exabytes was changed by an editting mistake to 512 instead of 1024 bytes. This problem didn't show up with tar, and slipped past testing. -- Dave Olson Life would be so much easier if we could just look at the source code.
olson@anchor.esd.sgi.com (Dave Olson) (08/01/90)
In <11041@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: | In <1990Jul27.161034.6142@watserv1.waterloo.edu> afleming@watsci.uwaterloo.ca (Allan Fleming) writes: | | | I am unable to read exabyte tapes that were written under OS 3.2 | | while using OS 3.3. All I get is a message from bru - warning end | | of volume one - while at the begining of the tape. I can read exabyte | | tapes written under OS 3.3 - Help, Allan Fleming | | This was a bug introduced into 3.3, and is one of the bugs fixed in the | 'real' 3.3 (3.3.1) release that will actually ship to customers. The | 3.3 release that some customers have received was shipped only to customers | requiring it for new hardware, and in some cases at the discretion of | sales offices for 'important' bug fixes. | | The work around is to read the tape with | dd if=/dev/tape bs=1k | bru -vtf - ... | | and similarly for writing. Note that this is not the same block size that | is set with -b, that is the blocking factor. | | The default block size for Exabytes was changed by an editting mistake | to 512 instead of 1024 bytes. This problem didn't show up with tar, | and slipped past testing. It has been pointed out to me that I did not make something clear here. You need to use the variable size block device for this to work. That is, if the Exabyte is unit #2, then you need to use dd if=/dev/rmt/tps0d2nsv bs=1k | bru -xvf - Otherwise the tape driver just sees this as a request for 2 512 byte blocks in 3.3 due to my editting error. I tend to forget that I have my system set up to use the variable block device by default. The other thing I failed to make clear, that is affecting some people, is that the 512 byte blocks cost you half of the tape capacity (when writing). This is due to the fact that the Exabyte drive always writes physical blocks of 1Kb, no matter what logical size is used. So if your blocksize modulo 1024 is not zero, you waste 1024 bytes less the modulo for every block written. -- Dave Olson Life would be so much easier if we could just look at the source code.