Very Computer

Hello,

I made a backup on SCSI tape, but now I can't read it because I forgot
the blocksize. Does anyone know how I can see what the blocksize on
the tape is?
--
Peter Mutsaers  |  Abcoude (Utrecht), |  Trust is a good quality

Otherwise, do a:

        dd if=/dev/rst0 of=/dev/null bs=64k count=1

...and see what dd tells you:

0+1 records in
0+1 records out
32768 bytes transferred in 2 secs (16384 bytes/sec)

(Note that 64 KB is the largest blocksize currently supported inside
the kernel by physio(), so there's no use in making the parameter
above larger.)

--
cheers, J"org

Never trust an operating system you don't have sources for. ;-)

Quote:> Not to acknowledge this nonstandard behaviour of IRIX but would it be a
> great effort to extend the max. blocksize in physio() and what would be
> the drawbacks of doing so?

Despite of this, i still think SGI is plain insane in this...

--
cheers, J"org

Never trust an operating system you don't have sources for. ;-)

    JW> restore(8) will figure it out by itself.

I used cpio since dump/restore does only backup 1 filesystem. I don't
trust to use /dev/nrst0 and put several dumps after each other on 1
tape. How do you deal with multiple (possibly) small filesystems and
dump/restore?

    JW> Otherwise, do a:

    JW>      dd if=/dev/rst0 of=/dev/null bs=64k count=1

    JW> ...and see what dd tells you:

    JW> 0+1 records in
    JW> 0+1 records out
    JW> 32768 bytes transferred in 2 secs (16384 bytes/sec)

    JW> (Note that 64 KB is the largest blocksize currently supported inside
    JW> the kernel by physio(), so there's no use in making the parameter
    JW> above larger.)

Reading this it is exactly as I thought is should be, yet I didn't see
the blocksize. The actual reasone was simple: The SCSI driver (for NCR
815) was failing! Restarting the generic install kernel with -c and
disabling the probing for all unneeded devices solved it.

So: the generic kernel (2.1.5 release and current) on the boot floppy
does not work well with SCSI tapes connected through an NCR 815. Is
this a known problem?
--
Peter Mutsaers  |  Abcoude (Utrecht), |  Trust is a good quality

[...]

Quote:

> (Note that 64 KB is the largest blocksize currently supported inside
> the kernel by physio(), so there's no use in making the parameter
> above larger.)

Not to acknowledge this nonstandard behaviour of IRIX but would it be a
great effort to extend the max. blocksize in physio() and what would be
the drawbacks of doing so?

Ciao/BSD - Matthias

--
*****************************************************************************

Solmsstrasse 44              Phone : +49-30-69409824 (MET!)
D-10961 Berlin
Germany
*****************************************************************************

: Hello,

: I made a backup on SCSI tape, but now I can't read it because I forgot
: the blocksize. Does anyone know how I can see what the blocksize on
: the tape is?

If you really want to get grubby, read back a fixed block, say 1 byte
in fixed mode, ensure it isn't going to suppress illegal length indicator,
it'll then check condition on having no read a full block's worth and the
sense data will tell you how much more you have to read (eeugh).

(more practically, what did you write it with? 512 bytes should be the
default for most things (tar/cpio unless you fiddled with B options) and
QIC type things).

You may be able to read the blocksize back by merely doing a scsi mode
sense and looking at the block descriptor -- the block length is in
bytes 5-7.

cheers,
al
(not speaking for HP..)

uriah # scsi -v -f /dev/rst0.ctl -c "1a 0 0 0 v:i1 0" 12 -i 12 \
'*i4 {Density} i1 {Number of blocks} i3 *i1 {Block length} i3'
Density:  21
Number of blocks:  0
Block length:  0

For a variable-mode recording, MODE SENSE reports a block length of 0.
The above is not for an HP drive, but i'm pretty sure they behave
identically.

Trying an oversized read() however should return the actual number of
bytes that have been read.

--
cheers, J"org

Never trust an operating system you don't have sources for. ;-)

dump/restore has other fine features like the fact that the TOC is
stored at the beginning of the dump, `restore -i', or a working
multi-level incremental system.  All this makes it useful for me.

(Making an oversized read().)

Quote:> So: the generic kernel (2.1.5 release and current) on the boot floppy
> does not work well with SCSI tapes connected through an NCR 815. Is
> this a known problem?

Hmm, well, re-reading it: of course, i don't use a GENERIC kernel
either.  But that's weird, i dunno what might be that specific in
GENERIC at all.

--
cheers, J"org

Never trust an operating system you don't have sources for. ;-)

Quote:>> > (Note that 64 KB is the largest blocksize currently supported inside
>> > the kernel by physio(), so there's no use in making the parameter
>> > above larger.)

By observation, I get much better streaming with dump on my tape drive
by using a blocksize of 128k compared with 64k.  I guess - though I
haven't checked it yet - that the reason for this is that it results
in a correspondingly bigger buffer inside dump, even though the writes
to the tape are no bigger.  This is particularly relevant to dump,
since it has to seek all over the disk, but probably affects tar and
maybe even dd in some circumstances.

-- Richard

--
"Nothing can stop me now... except microscopic germs"

Thanks J"org, that was all I wanted to know :-)))))

Ciao/BSD - Matthias

--

*  Solmsstrasse 44              Phone:    +49-30-69409824   ME(S)T !!          *
*  D-10961 Berlin               FAX/DATA: +49-30-69409825                      *
*  Germany                                                                     *

   st0(ahc0:4:0): timed out in dataout phase, SCSISIGI = 0x0
   st0(ahc0:4:0): BUS DEVICE RESET message queued.
   Bus Device Reset Message Sent
   ahc0:A:4: no active SCB for reconnecting target - issuing ABORT
   SAVED_TCL == 0x40

If I try it again, I get this:

   panic: ahc0: Timed-out command times out again

and then I am history.

Everything works fine if I use /dev/rst0, and in fact if I only
read/seek through /dev/nrst0 it works fine, and everything else
I have put on the bus like hard drives and ZIP drives worked OK.

The DAT drive works without a hitch through /dev/nrst0 on my
SunOS 4.X SPARC, so I have not bothered to look into it much.

Larry