martin@mwtech.UUCP (Martin Weitzel) (11/03/90)
Some days ago I upgraded from ISC 386/ix 2.02 to 2.2. Since I wanted to re-partition my disk I made a full installation. Now I have some problems (or rather inconveniences) reading the tape cartridges with my backups. My tape drive is an ARCHIVE ST-600 with a SC-499R controller. The problem is, that "cpio -i" as well as "dd" end with an I/O-Error on each and every tape, making it impossible to get to some of the files which are the last ones on the tape. (It's possible to play some tricks with pipelines thru "dd" and conv=sync,noerror to fully read in the tapes, so I had nothing really lost.) I'm sure, that the behavior was correct with 2.02, since I did a "cpio -t" on all the tapes after making the backup, just to be sure that everything was there. What further bothers me is the fact that even "cpio -o" ends with I/O- errors now, so I assume that not all files get out to the tape. (Of course I could also circumvent this by backing up a rather large file which I don't really need as the last one.) But this are all work-arounds, which make tape handling rather inconvenient, especially with the current bug in Archives tape drivers, that slows the things down after two or three operations that end with I/O-Errors, making it necessary to re-boot very often. Does anybody outhere now what's going on? -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
rsj@wa4mei.UUCP (Randy Jarrett) (11/28/90)
In <950@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >Some days ago I upgraded from ISC 386/ix 2.02 to 2.2. Since I wanted to >re-partition my disk I made a full installation. Now I have some >problems (or rather inconveniences) reading the tape cartridges with >my backups. My tape drive is an ARCHIVE ST-600 with a SC-499R controller. >The problem is, that "cpio -i" as well as "dd" end with an I/O-Error >on each and every tape, making it impossible to get to some of the >files which are the last ones on the tape. (It's possible to play some >tricks with pipelines thru "dd" and conv=sync,noerror to fully read in >the tapes, so I had nothing really lost.) >I'm sure, that the behavior was correct with 2.02, since I did a >"cpio -t" on all the tapes after making the backup, just to be sure >that everything was there. >What further bothers me is the fact that even "cpio -o" ends with I/O- >errors now, so I assume that not all files get out to the tape. (Of >course I could also circumvent this by backing up a rather large file >which I don't really need as the last one.) >But this are all work-arounds, which make tape handling rather inconvenient, >especially with the current bug in Archives tape drivers, that slows the >things down after two or three operations that end with I/O-Errors, >making it necessary to re-boot very often. >Does anybody outhere now what's going on? >-- >Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83 Are you getting the errors when you make the tapes or when you read them back in to verify them. If it is on the read it might be the same problem I have seen before that is caused if you don't use the 'B' option with the cpio when reading in. On the problem with the drivers, I havn't seen or heard of that one before. The main problem that seems to be happening when you get an error or abort the read or write of a tape is that you end up with a hung process that can't be killed and you can't kill and also the tape is unusable until you reboot the system. -- Randy Jarrett WA4MEI UUCP ...!{emory,gatech}!wa4mei!rsj | US SNAIL: P.O. Box 941217 PHONE +1 404 493 9017 | Atlanta, GA 30341-0217
jdeitch@jadpc.cts.com (Jim Deitch) (11/29/90)
In article <936@wa4mei.UUCP> rsj@wa4mei.UUCP (Randy Jarrett) writes: >In <950@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: > >>Some days ago I upgraded from ISC 386/ix 2.02 to 2.2. Since I wanted to >>re-partition my disk I made a full installation. Now I have some >>problems (or rather inconveniences) reading the tape cartridges with >>my backups. My tape drive is an ARCHIVE ST-600 with a SC-499R controller. > >>The problem is, that "cpio -i" as well as "dd" end with an I/O-Error >>on each and every tape, making it impossible to get to some of the >>files which are the last ones on the tape. (It's possible to play some >>tricks with pipelines thru "dd" and conv=sync,noerror to fully read in >>the tapes, so I had nothing really lost.) > >>I'm sure, that the behavior was correct with 2.02, since I did a >>"cpio -t" on all the tapes after making the backup, just to be sure >>that everything was there. > >>What further bothers me is the fact that even "cpio -o" ends with I/O- >>errors now, so I assume that not all files get out to the tape. (Of >>course I could also circumvent this by backing up a rather large file >>which I don't really need as the last one.) > >>But this are all work-arounds, which make tape handling rather inconvenient, >>especially with the current bug in Archives tape drivers, that slows the >>things down after two or three operations that end with I/O-Errors, >>making it necessary to re-boot very often. > >>Does anybody outhere now what's going on? > > >>-- >>Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83 > >Are you getting the errors when you make the tapes or when you >read them back in to verify them. If it is on the read it might >be the same problem I have seen before that is caused if you don't >use the 'B' option with the cpio when reading in. > >On the problem with the drivers, I havn't seen or heard of that one >before. The main problem that seems to be happening when you get an >error or abort the read or write of a tape is that you end up with a >hung process that can't be killed and you can't kill and also the tape >is unusable until you reboot the system. > > I have this problem with the -B and without. If you abort a read or write the bug seems to happen quicker. A reboot is necessary to make the tape useable again. The hung process is not killable at all. Interestingly, I talked to a gentleman at Archive (I lost his name) the Wednesday before thanksgiving. He said that he was going to take a system home with ISC 2.2 over the holiday. He also said that Archive hasn't heard of this problem before. I know I reported it 3 times to them! I haven't tried to call back in to Archive to find out if he could recreate the problem. Maybe if Archive has news they will post something. Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch