lkml.org 
[lkml]   [2002]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectblocksize limitations in scsi tape driver (st) when used with DLT1 tape drives?
Hi!

I'm having an odd problem here. I use SuSE Linux 8.0 with kernel
2.4.18-64GB-SMP, arkeia as backup software and a Tandberg
VS80 (DLT1) streamer.

After some trial and error I found out that I have to use a fixed block
size for DLT streamers (same applies to LTO ones). This document,
found at HP, tells you in details about which blocksize to use:
http://www.hp.com/cposupport/information_storage/support_doc/lpg50167.html

Now I told arkeia to use a blocksize of 65536, 32768 and 16384 and it
could not write to the tape. All I got in the log was:

Sep 4 22:04:50 filesrv kernel: st: Unloaded.
Sep 4 22:08:40 filesrv kernel: st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Sep 4 22:08:40 filesrv kernel: st0: Block limits 2 - 16777214 bytes.
Sep 4 22:08:41 filesrv kernel: st0: Incorrect block size.
Sep 4 22:08:45 filesrv kernel: st0: Write not multiple of tape block size.

Sep 4 23:20:06 filesrv kernel: st: Unloaded.
Sep 4 23:20:30 filesrv kernel: st: Version 20020205, bufsize 524288, wrt 522240, max init. bufs 16, s/g segs 64
Sep 4 23:20:30 filesrv kernel: st0: Block limits 2 - 16777214 bytes.
Sep 4 23:20:33 filesrv kernel: st0: Incorrect block size.
Sep 4 23:20:35 filesrv kernel: st0: Write not multiple of tape block size.

(As you might have notice in the second case I'm loading st with buffer_kbs=512,
max_buffers=16 and max_sg_segs=64 but that makes no difference compared to the
default values)


BUT now comes the cloo: at and below a blocksize of 8192 it was possible
to write to the tape. At 1024 the backup slowed down from 20 min to 4 hours,
but at 8192 the backup speed is normal (the later on with the st options
you can see above, but haven't tested if that makes a difference).

LTO drives in contrast to DLT drives are happy with a blocksize of 1024
and backup speed is normal at this blocksize.

Everytime when arkeia could not write to the tape I checked with mt to
display the blocksize and I verified that arkeia set it to the value I
told it to. Now with arkeia set to a blocksize of 8192:

filesrv:~ # mt -f /dev/st0 status
drive type = Generic SCSI-2 tape
drive status = 1073750016
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 8192 bytes. Density code 0x40 (unknown).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN

I think there must be something wrong in the scsi tape driver(st).
Can someone shine some light on this?

PS: Reply-to set to linux-scsi.

--
MfG / Regards
Friedrich Lobenstock

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.053 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site