[Dump-users] Re: help! block size emergency

[Dragan K. <dk...@ly...>]

| > How come? The mt subcommand "setblk 0" is supposed 
| > to set variable-sized blocks for future writes 
| > (whatever gets transferred in one transaction). It 
| > is ignored for reads. The tape drive reads blocks 
| > as they were written regardless of any "setblk" 
|
| ... I know from experience that "mt setblk 0" does 
| have an effect on reads. On a number of occasions, 
| I've had tapes that were unreadable with the default 
| setblk setting of my drive (whatever it is), but 
| after issuing "mt setblk 0" I have been able to read 
| them just fine...

OK. It is a bug in st driver that needs to be fixed.

In my experience setting the block size to non-zero 
value only affects future writes. Tape reads read the 
whole block, if sufficient space is reserved in the 
caller's buffer and the driver returns the number of 
bytes actually read. If less bytes are requested, the 
drive will return the number of bytes left unread, if 
asked, but will swallow the residual, if not asked to
retrieve them.

If Anthony set variable block size, dd with bs=64k
would always read all blocks <=64k and the restore
on the other side of the pipe would be happy.

Now if he set the block size to an obviously 
unmotivated value of 32000 bytes (unless it's his
short-hand for 32k), it still shouldn't prevent the dd 
from reading any actual block size <=64k. But he only 
fumbled with 32000 in between, after the emergency 
plea, as far as I understood.


Who maintains st.c? I found out that the subcmd "tell"
of "mt" returns an I/O error on my LTO-2, because of
the following wrong code in function "get_location":

   2775     if ((STp->device)->scsi_level < SCSI_2) {
   2776         scmd[0] = QFA_REQUEST_BLOCK;
   2777         scmd[4] = 3;
   2778     } else {
   2779         scmd[0] = READ_POSITION;
   2780 /*      if (!logical && !STp->scsi2_logical)
   2781             scmd[1] = 1;
   2782 */  }

Commenting out lines 2780/2782 is my fix for "mt tell" 
to work without error and to return the correct record 
number at the current position on the tape. I haven't
tested it with other kinds of drives on Linux but I 
can remember that SCSI cmd "0x34,0,0,0,0,0,0,0,0,0" 
worked properly for DDS, DLT and Ecrix on HP-UX.

Another little bug in st.c is that it rewinds the tape
upon boot, because it cannot reconstruct the
"file number" and "record number" [respective to the
beginning of the current "file number"] fields in the
output of "mt status", unless it keeps track of the tape movements itself. The "mt status" itself returns
something like:

  p2:/local # mt status
  drive type = Generic SCSI-2 tape
  drive status = 1107296256
  sense key error = 0
  residue count = 0
  file number = 1
  block number = 2691202
  Tape block size 0 bytes. Density code 0x42 (unknown).
  Soft error count since last status=0
  General status bits on (1010000): ONLINE IM_REP_EN p2:/local #

i.e. no terminating line-feed.

A third unexpected behaviour of Linux "st.c" is 
that "mt fsr #" or "mt bsr #" stops after first 
intervening file mark instead of just counting it as 
just another record.


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005