🚀 go-pugleaf

In article <1992Dec9.101922.618@nexcom.hanse.de> helmut@nexcom.hanse.de  
(Helmut Schoenborn) writes:
#My Sony SDT 2000 DAT-Drive works fine using tar on /dev/rst0.
#But the attempt to dump/restore failed. Dump reports no errors.
#According to man sd for Exabyte-Drives whith the command
#
#	dump 0fs /dev/rst0 1200000 /dev/rsd0a
#
#a level 0 dump was written on the tape. Trying to restore by
#
#	restore if /dev/rst0
#	
#I receive
#
#	Tape/disk read error: I/O error
#	
#and on console
#
#	st: cmd = 0x8 sr_io_status = 2H
#    Sense key = 0x0  Sense Code = 0x0
#
#The tape is ok, tar does it's job read/write, and I'm confused. Any hints  
? 
#-- 

I think this is because your drive is not set to fixed block mode for  
restore which it was during dump.  What I do, and this has ALWAYS worked,  
is a 

localhost:4# restore i
/dev/rxt0: I/O error

Then I do a

localhost:5# restore if /dev/nrst0

and the restore works just fine.  The default device for tape is /dev/rxt0  
which, if I remember correctly, is a exabyte device which uses a fixed  
block length....

I hope this helps...

#                     __   __
#Helmut Schoenborn 	/\_\_/\_\		email:  
helmut@nexcom.hanse.de
#Rheingoldweg 13 	\/_/ \/_/		voice (040) 810 816

--
Paul S. Sears                *  sears@uh.edu (NeXT Mail OK)
The University of Houston    *  suggestions@tree.egr.uh.edu (NeXT
Engineering Computing Center *  comments, complaints, questions)
NeXT System Administration   *  DoD#1967 '83 NightHawk 650SC 
          >>> SSI Diving Certification #755020059 <<<
"Programming is like sex: One mistake and you support it a lifetime."

In article <1gkvvfINN66@menudo.uh.edu> sears@tree.egr.uh.edu (Paul S.
Sears) writes: ...

   In article <1992Dec9.101922.618@nexcom.hanse.de> helmut@nexcom.hanse.de  
   (Helmut Schoenborn) writes: ...
   #I receive
   #
   #	Tape/disk read error: I/O error

   ... I think this is because your drive is not set to fixed block mode for  
   restore which it was during dump.  What I do, and this has ALWAYS worked,  
   is a 

   localhost:4# restore i
   /dev/rxt0: I/O error

   Then I do a

   localhost:5# restore if /dev/nrst0

   and the restore works just fine.  The default device for tape is /dev/rxt0  
   which, if I remember correctly, is a exabyte device which uses a fixed  
   block length....

This very common problem isn't fixed vs. variable block length mode,
per se, but "allow illegal length" vs. "inhibit illegal length".
Sear's workaround is a ineligant but functional way of getting the
"allow illegal length" mode set.  A cleaner way is to compile the
following and call the executable mtalill.  Then do "mtalill
/dev/nrst0" before your restore.  (I do it in the /etc/rc.local every
time the machine boots.)

#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <nextdev/scsireg.h>
#include <sys/file.h>

main(int argc, char *argv[]){
  int fd;

  if(argc != 2){
    fprintf(stderr, "Usage: %s device\n", argv[0]);
    exit(1);
    }

  if((fd = open(argv[1], O_RDONLY, 0)) < 0){
    perror(argv[1]);
    exit(1);
  }

  if(ioctl(fd, MTIOCALILL, NULL) < 0){
    perror("doing MTIOCALILL ioctl");
    exit(1);
  }

  if(close(fd) < 0){
    perror("closing");
    exit(1);
  }

  exit(0);
}

In article <MAX.92Dec16102112@Kolmogorov.gac.edu>
max@Kolmogorov.gac.edu (Max Hailperin) (yes that's me) writes:

   [A bunch of stuff about tape read errors that would have been
    correct, except that I'm brain dead and got "allow" and "inhibit"
    backwards.]

The correct mode of operation for restoring from a DAT drive is
*inhibit* illegal length, *not* allow.  This is what Sears's
workaround does by using the exabyte device.  The correct solution,
then, is *not* the mtalill program I posted, but rather the converse,
which I naturally call mtinill.  This is what I actually run in my
/etc/rc.local.  Please excuse my earlier error.

#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <nextdev/scsireg.h>
#include <sys/file.h>

main(int argc, char *argv[]){
  int fd;

  if(argc != 2){
    fprintf(stderr, "Usage: %s device\n", argv[0]);
    exit(1);
    }

  if((fd = open(argv[1], O_RDONLY, 0)) < 0){
    perror(argv[1]);
    exit(1);
  }

  if(ioctl(fd, MTIOCINILL, NULL) < 0){
    perror("doing MTIOCINILL ioctl");
    exit(1);
  }

  if(close(fd) < 0){
    perror("closing");
    exit(1);
  }

  exit(0);
}

I'm suprised no one mentioned dd in this discussion (or I missed it).  I have used dump/restore piped
through dd for some time specifying ibs and obs as 51200.  If you create seperate entries as in
ibs=51200 obs=51200 as opposed to bs=51200 you actually get noticable performance improvment. (I'm not
sure about NeXT, but it feels faster)

I did a recent timeing, on a NST to a DAT with tar, compress, and dd and it took about 40Minutes to 
back up about 300 Mb.  I thought this was pretty good for gnutar.

I was lead to believe that large block sizes were much more efficient on helical scan tape devices
like DAT and EXABYTE. In addition running through dd seems to fix up any block size problems that
occur.

Hope this helps


-- 
---------------------------------------------------------------------------
Ian Jefferson 	ijeff@ccs.carleton.ca No NeXT mail please!
		ijeff@computeractive.on.ca NeXT mail please!