public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Friedrich Lobenstock <fl@fl.priv.at>
To: Linux-SCSI Mailingliste <linux-scsi@vger.kernel.org>
Cc: Linux-Kernel Mailingliste <linux-kernel@vger.kernel.org>
Subject: blocksize limitations in scsi tape driver (st) when used with DLT1 tape drives?
Date: Thu, 05 Sep 2002 21:35:50 +0200	[thread overview]
Message-ID: <3D77B216.8070205@fl.priv.at> (raw)

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


             reply	other threads:[~2002-09-05 19:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fl@fl.priv.at>
2002-09-05 19:35 ` Friedrich Lobenstock [this message]
2002-09-05 20:02   ` blocksize limitations in scsi tape driver (st) when used with DLT1 tape drives? Dag Nygren
2002-09-05 20:59     ` Friedrich Lobenstock
2002-09-06  0:15       ` jw schultz
2002-09-05 20:14   ` 2.5.xx kernels won't run on my Athlon boxes Kirk Reiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D77B216.8070205@fl.priv.at \
    --to=fl@fl.priv.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox