FL17@DLRVMBS.BITNET (03/20/91)
To: info-iris@brl.mil 19-Mar-1991 ExaByte feom problem Hi, the sequence mt -t /dev/nrexa rewind mt -t /dev/nrexa feom bru -cvf /dev/nrexa files ... works nicely on our 4D70GT running IRIX 3.3.1 to create multiple archives on an ExaByte tape as long as the machine is not rebooted. If, however, the machine is rebooted, feom doesn't work as expected and a new archive is written at the beginning of the tape overwriting what was already on tape. If the machine is not rebooted again, the next archive is appended to the archive already on tape. Does anyone out there have any explanation or workaround ? Thanks and best regards Ralf Beyer --------------------------------------------------------------------- Ralf Beyer | German Aerospace Research Establishment | Braunschweig Research Center | Institute for Flight Guidance | Flughafen | D-3300 Braunschweig, Fed. Rep. of Germany | Phone: (0531) 395-2530 | Fax: (0531) 395-2550 | Email: fl17@dlrvmbs.bitnet | Email (local): beyer@bflsgu ---------------------------------------------------------------------
FL17@DLRVMBS.BITNET (03/21/91)
To: info-iris@brl.mil 19-Mar-1991 ExaByte feom problem Hi, the sequence mt -t guest@remhost:/dev/nrexa rewind mt -t guest@remhost:/dev/nrexa feom bru -cvf guest@remhost:/dev/nrexa files ... works nicely on our 4D25GT with the remote host being a 4D70GT to create multiple archives on an ExaByte tape as long as the remote host is not rebooted. If, however, the remote host is rebooted, feom doesn't work as expected and a new archive is written at the beginning of the tape overwriting what was already there. If the remote host is not rebooted again, the next archive is appended to the archives already on tape as expected. If the same procedure is run on a local host, i.e. mt -t /dev/nrexa rewind mt -t /dev/nrexa feom bru -cvf /dev/nrexa files ... this error does not show up. Does anyone out there have any explanation or workaround ? Both machines are running IRIX 3.3.1. Thanks and best regards Ralf Beyer --------------------------------------------------------------------- Ralf Beyer | German Aerospace Research Establishment | Braunschweig Research Center | Institute for Flight Guidance | Flughafen | D-3300 Braunschweig, Fed. Rep. of Germany | Phone: (0531) 395-2530 | Fax: (0531) 395-2550 | Email: fl17@dlrvmbs.bitnet | Email (local): beyer@bflsgu ---------------------------------------------------------------------
olson@anchor.esd.sgi.com (Dave Olson) (03/21/91)
In <9103200941.aa07171@VGR.BRL.MIL> FL17@DLRVMBS.BITNET writes: | the sequence | | mt -t guest@remhost:/dev/nrexa rewind | mt -t guest@remhost:/dev/nrexa feom | bru -cvf guest@remhost:/dev/nrexa files ... | | works nicely on our 4D25GT with the remote host being a 4D70GT to create | multiple archives on an ExaByte tape as long as the remote host is not | rebooted. If, however, the remote host is rebooted, feom doesn't work as | expected and a new archive is written at the beginning of the tape overwriting | what was already there. If the remote host is not rebooted again, the next | archive is appended to the archives already on tape as expected. The bug is in the setup of the drive on the very first use after reboot (or after a tape is first inserted, if I remember correctly). The hack work-around till 4.0 is to add after the rewind: mt ... fsr 1 and ignore any resulting errors (which might occur if the tape is blank). Sorry about that; it only happens on the Exabyte, due to the fact that it doesn't support space to EOD, and it therefore has to be faked; some condition codes weren't set/checked correctly in this one case. -- Dave Olson Life would be so much easier if we could just look at the source code.