This is tape-woes in view mode; [Up]
Date: Sun 01-Oct-1991 14:23:59 From: MeyerGru@Informatik.TU-Muenchen.DE (Uwe Meyer-Gruhl) Subject: tape woes Hi NeXTers, I don't know if both questions belong into this group, but I'll post them here anyway. The first one seems to be NeXT-specific and the second is in some way related to the first. Here goes: I have a NeXT color slab with an external SCSI tape drive attached. It's a Tandberg 3820 which handles QIC-24, -120, -150 and -525. The problem is, when I want to do several DUMPs (or TARs) to the same tape, I can never read the second (nor the third) file on the tape. I think, the "right thing" to do is something like that: > mt -f /dev/nrst0 rewind > dump 0vbf 64 /dev/nrst0 /dev/rsd0a (or tar .....) > mt -f /dev/nrst0 weof (although tar should write one, so I tried without this, too) > dump 0vbf 64 /dev/nrst0 /dev/rsd1a (2nd file) > mt -f /dev/nrst0 weof 2 This works just fine, _but_: if I try to skip the first dump (or tar) and read the second, by issuing: > mt -f /dev/nrst0 rewind > mt -f /dev/nrst0 fsf (skip first file, but I tried also two skips) I get an error. This is a "bad thing", because I don't want to sacrifice a whole 525 MByte tape for every two nibbles archived...so what is to be done about this one? This leads to my second question. The installation manual states, that this particular tape drive supports reading of QIC-24, -120, -150 and -525 tapes, and that it can also write any of the standards above QIC-24. I can read QIC-24 (60MByte) and QIC-150 (150MByte) tapes written by an Archive streamer attached to a SUN at work. However, I can _neither_ write QIC-24 (which is what I expected) _nor_ QIC-150. Since the Archive streamer doesn't support larger tapes than these, my data exchange is thus limited to one direction. If I try to write QIC-24 or QIC-150 tapes, I get a "tape write error", and the tape motor isn't even started. Matter-of-fact I wonder how the type is determined at all, because IMHO the cases of the cassettes are indistiguishable between _all_ quarter-inch-formats (maybe there are encodings on the tape?). I _can_ write to QIC-525 tapes, what should be clear from the first question already. So, is there a typo in the manual, does Tandberg pretend something, NeXT-specific software problems or whatelse? Just wondering, Uwe P.S.: As I stated above, maybe I should ask these questions in comp.periphs.scsi, but I'm not sure where the problems stem from. If you think these are problems of no interest to others, reply by email. Sorry that it has gotten that longish, thanks for reading it anyway.
Date: Sun 01-Oct-1991 20:27:49 From: grd@ccrma.stanford.edu (glen diener) Subject: Re: tape woes In article <1991Oct1.142359.9942@Informatik.TU-Muenchen.DE> MeyerGru@Informatik.TU-Muenchen.DE (Uwe Meyer-Gruhl) writes: > > Hi NeXTers, > > > I don't know if both questions belong into this group, but I'll post them > here anyway. > > The first one seems to be NeXT-specific and the second is in some way related > to the first. Here goes: > > I have a NeXT color slab with an external SCSI tape drive attached. It's a > Tandberg 3820 which handles QIC-24, -120, -150 and -525. > > The problem is, when I want to do several DUMPs (or TARs) to the same tape, > I can never read the second (nor the third) file on the tape. I think, the > "right thing" to do is something like that: > > > mt -f /dev/nrst0 rewind > > dump 0vbf 64 /dev/nrst0 /dev/rsd0a (or tar .....) > > mt -f /dev/nrst0 weof (although tar should write one, > so I tried without this, too) > > dump 0vbf 64 /dev/nrst0 /dev/rsd1a (2nd file) > > mt -f /dev/nrst0 weof 2 > > This works just fine, _but_: if I try to skip the first dump (or tar) and read > the second, by issuing: > > > mt -f /dev/nrst0 rewind > > mt -f /dev/nrst0 fsf (skip first file, but I tried > also two skips) > > I get an error. This is a "bad thing", because I don't want to sacrifice a > whole 525 MByte tape for every two nibbles archived...so what is to be done > about this one? > -- stuff deleted > Uwe Meyer-Gruhl, Institut fuer Informatik, TU Muenchen, Germany > email: MeyerGru@Informatik.TU-Muenchen.DE I had much the same problem, so I rewind the tape after writing every archive, then fast forward it. Here are a few lines of code from my dump script... #first dump done, rewind the tape mt -f ${LOCALDUMPDEV} rewind sleep 90 #fast forward for next archive mt -f ${LOCALDUMPDEV} fsf ${TAPELOC} sleep 90 #now write the archive .... A kludge, I know, but it does work. I've found that I also need to bracket mt with sleep commands... mt returns before the tape drive (in my case, an Exabyte) has actually settled into a state where its ready to accept another command!! Without the sleep command, the second mt above will die with a tape i/o error. -glen diener grd@ccrma.stanford.edu
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.