felix@warbucks.ai.sri.com (Felix Ingrand) (06/06/90)
We are running 4.0.3 on a Sun-4/280. Our Exabyte is on the SCSI port using the driver rst0. It looks like we are having some troubles with the file positioning on the tape. We are only using nrst0, and we are doing the following: tar xf /dev/nrst0 mt -f /dev/nrst0 rew mt -f /dev/nrst0 fsf 1 dump 4dsbf 54000 6000 100 /dev/nrst0 /dev/... And the dump fail with the following error: DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: mapping (Pass II) [directories] DUMP: estimated 8542 blocks (4.17MB) on 0.00 tape(s). DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Media write error 4 feet into volume 1 and the st driver says: Jun 5 13:22:43 sunset vmunix: st0: illegal command Jun 5 13:22:43 sunset vmunix: st0: failed cmd = a 0 0 c8 0 0 Jun 5 13:22:43 sunset vmunix: st0 error: sense key(0x5): illegal request Jun 5 13:22:43 sunset vmunix: sense = 70 0 5 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22 f3 99 0 0 Jun 5 13:22:43 sunset vmunix: Felix
paula@beaver.cs.washington.edu (Paul Allen) (06/08/90)
In article <8562@brazos.Rice.edu> felix@warbucks.ai.sri.com (Felix Ingrand) writes: >We are running 4.0.3 on a Sun-4/280. Our Exabyte is on the SCSI port >using the driver rst0. It looks like we are having some troubles with the >file positioning on the tape. We are only using nrst0, and we are doing >the following: > >tar xf /dev/nrst0 >mt -f /dev/nrst0 rew >mt -f /dev/nrst0 fsf 1 >dump 4dsbf 54000 6000 100 /dev/nrst0 /dev/... > >And the dump failed... I've been using Exabyte drives with Sun's 3.5 SCSI driver for a long time with no trouble. The piece of my backup system that actually copies the data to tape has a 1Mb buffer and calls write(2) with a third argument of 1048576. This worked fine until I upgraded one of my Exabyte servers to 4.0.3. I got no indication of write failure, but could not read the resulting tapes! Through experimentation, I determined that using a write size of 32768 or less would result in a good tape. I would suggest trying a dump block size of 64 or less. Does anyone have any wisdom to share about 4.0.3 and Exabyte drives? I've heard it stated that you simply cannot use an Exabyte with 4.0.3 without a patch tape. While there may be a patch for some sort of a problem, I'm certainly using one of my Exabyte drives under 4.0.3 without it. I'm going to be upgrading a machine to 4.1, perhaps tomorrow. One of the experiments on my list is to attach an Exabyte and check it out. I'll have something to say in a week or so. Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
dar@nucleus.mi.org (Dario Alcocer) (06/08/90)
felix@warbucks.ai.sri.com (Felix Ingrand) writes: >We are running 4.0.3 on a Sun-4/280. Our Exabyte is on the SCSI port >using the driver rst0. It looks like we are having some troubles with the >file positioning on the tape. We are only using nrst0, and we are getting >the following: >Jun 5 13:22:43 sunset vmunix: st0: illegal command >Jun 5 13:22:43 sunset vmunix: st0: failed cmd = a 0 0 c8 0 0 >Jun 5 13:22:43 sunset vmunix: st0 error: sense key(0x5): illegal request >Jun 5 13:22:43 sunset vmunix: sense = 70 0 5 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22 f3 99 0 0 >Jun 5 13:22:43 sunset vmunix: >Felix I'm not exactly sure what's the problem, but I have a few observations: The command that failed was a WRITE command; 1st byte in cmd is the operation code. In the failed cmd, the 2nd byte is 0, implying that a variable-length block write of 0xc800 bytes (3rd, 4th, and 5th bytes in cmd) was requested. However, if the length isn't between MINBLKLEN and MAXBLKLEN, you'll get an illegal request sense key, as per the ANSI document. Incidentlly, according to the Exabyte docs (EXB-8200 User's Manual) I have, a maximum variable length block can be at most 0x3c00, which is _smaller_ than 0xc800 bytes, may be a problem there, don't know what model you're using. Also, the drive may have already been in fixed-length block mode, which will also result in illegal request. That's the SCSI end of things. I'm not sure as to tar and mt, I'm not familiar enough to know if there is something they are doing to cause this. Hope this helps somewhat. Dario Alcocer | Internet: dar@nucleus.mi.org Associate Software Engineer | voice: 619-673-2161, x5119 Emerald Systems | Standard disclaimers apply.
kuhn@zariski.harvard.edu (Robert Kuhn) (06/08/90)
In article 10203 of this group Robert E. Toense writes: > There are three possible conditions for writing files on an Exabyte > drive: > > 1) Beginning of tape, > 2) Immediately following a write (no intervening motion), and > 3) Immediately following writing a filemark (no intervening motion). > > One of these conditions must exist or the write will fail. This may be true for SOME Exabytes, with SOME drivers, but is by no means universal. We have an Exabyte (supplied by Aviv Corp) attached to the SCSI 3 board of our 4/280 running SunOS 4.0.3. We perform unattended backups on this device, a full dump once a week, followed by 6 daily incrementals. Since one cannot be assured of tape position being maintained, we reposition to the beginning of the tape, and then advance to the correct tape position before each dump. Here is our Sunday script: /usr/bin/mt -f /dev/nrst1 rew /usr/bin/sleep 120 /usr/bin/mt -f /dev/nrst1 fsf 2 /usr/bin/sleep 120 /usr/bin/echo "Making a level 6 dump for zariski onto exabyte at:" date /etc/dump 6ucfbsdn /dev/nrst1 56 5190 4100000 /dev/rxy0h /usr/bin/echo "Level 6 dump for zariski finished at:" /usr/bin/date /usr/bin/mt -f /dev/nrst1 rew One problem with the script discussed by Mr Toense: tar xf /dev/nrst0 mt -f /dev/nrst0 rew mt -f /dev/nrst0 fsf 1 dump 4dsbf 54000 6000 100 /dev/nrst0 /dev/... has been discussed before, namely, the need to pause between operations that reposition the tape. Whatever else may be the problem, the simple prescription for successful tape writing on an Exabyte which he gives is wrong. Yours, Robert M. Kuhn Director of Computing in Mathematics Department of Mathematics Harvard University 1 Oxford Street Cambridge, MA 02138
lbd@alux4.att.com (06/12/90)
Last November, we upgraded from 3.5 directly to 4.0.3. We have used Exabyte tape drives for backups on both OS's with no problems, using the exact same dump script. The dump command we use is: /usr/etc/dump 1ubdfs 126 54000 /dev/nrst1 6000 / (our exabyte drive is rst1). This is on a 3/280 server, but we run the exact same command on 15 other servers running 4.0.1 or 4.0.3 and have never had a problem. We use the standard Sun SCSI driver, too. The only problem I've ever run into is trying to read 3.5 tapes into 4.0.3. Using a blocking factor of 2 with restore works around it. In short, we installed no patch and have had no trouble. Leslie Dreyer, Bell Labs att!alux4!lbd