From: ael <law_ence.dev@ntlworld.com>
To: linux-scsi@vger.kernel.org
Subject: st.c block limits
Date: Tue, 30 Jul 2002 21:20:04 +0100 [thread overview]
Message-ID: <3D46F4F4.1090703@ntlworld.com> (raw)
I have a scsi tape drive:-
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: AIWA Model: TD-20001 Rev: 0159
Type: Sequential-Access ANSI SCSI revision: 02
It has worked perfectly for several years, but from kernel 2.4.10 st.c
started to report a 24-bit block limit: st0: Block limits 1 - 16777215
bytes. I am now on stock 2.4.18 with static char *verstr = "20020205".
The above drive is a NS-20 drive with default block size of 512 and 20G
blocks: so a range of 25 bits for the block number is needed.
So when I attempt to write to the tape beyond block 2^24,
I get an error like:
# tar -cf /dev/ntape blah_home.tar.bz2; mt tell
tar: /dev/ntape: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now
At block 17832312.
With:
kernel: st0: Block limits 1 - 16777215 bytes.
in the kernel log.
Now I *think* that I used to write to the end of tapes without hitting this
2^24 block limit. I guess that I can work around by setting a larger block
size. But is there a fix? Or is the 24-bit limit built into the scsi tape
protocol? Since I used to fill 2 tapes to complete a backup, I must have
written beyond block (2^24 -1).
Sorry if this is an FAQ. I did google and found nothing directly relevant.
When did st.c change and why? I did turn on DEBUG, and I append a few
entries, although I am not sure that it helps much:
Jul 30 16:49:28 conquest3 kernel: st: Version 20020205, bufsize 32768, wrt
30720, max init. bufs 4, s/g segs 16
Jul 30 16:49:28 conquest3 kernel: Attached scsi tape st0 at scsi0, channel
0, id 0, lun 0
Jul 30 16:49:28 conquest3 kernel: st: Allocated tape buffer 0 (32768 bytes,
1 segments, dma: 1, a: c01e8000).
Jul 30 16:49:28 conquest3 kernel: st: segment sizes: first 32768, last
32768 bytes.
drwx------ 2 ael ael 4096 Nov 3 2001 Mail
Jul 30 16:49:28 conquest3 kernel: st0: Block limits 1 - 16777215 bytes.
Jul 30 16:49:28 conquest3 kernel: st0: Mode sense. Length 11, medium 85,
WBS 10, BLL 8
Jul 30 16:49:28 conquest3 kernel: st0: Density 0, tape length: 0, drv buffer: 1
Jul 30 16:49:28 conquest3 kernel: st0: Block size: 512, buffer size: 32768
(64 blocks).
After switching to 1K blocks and fsf'ing past existing data:-
--------------------------------------------------------------
Jul 30 17:28:50 conquest3 kernel: st0: Setting block size to 1024 bytes.
Jul 30 17:28:50 conquest3 kernel: st0: Rewinding tape.
Jul 30 17:28:52 conquest3 kernel: st0: Block limits 1 - 16777215 bytes.
Jul 30 17:28:52 conquest3 kernel: st0: Mode sense. Length 11, medium 85,
WBS 10, BLL 8
Jul 30 17:28:52 conquest3 kernel: st0: Density 0, tape length: 0, drv buffer: 1
Jul 30 17:28:52 conquest3 kernel: st0: Block size: 1024, buffer size: 32768
(32 blocks).
Jul 30 17:28:52 conquest3 kernel: st0: Rewinding tape.
Jul 30 17:29:36 conquest3 kernel: st0: Block limits 1 - 16777215 bytes.
Jul 30 17:29:36 conquest3 kernel: st0: Mode sense. Length 11, medium 85,
WBS 10, BLL 8
Jul 30 17:29:36 conquest3 kernel: st0: Density 0, tape length: 0, drv buffer: 1
Jul 30 17:29:36 conquest3 kernel: st0: Block size: 1024, buffer size: 32768
(32 blocks).
Jul 30 17:29:36 conquest3 kernel: st0: Spacing tape forward over 12 filemarks.
Jul 30 17:32:28 conquest3 kernel: st0: Block limits 1 - 16777215 bytes.
Jul 30 17:32:28 conquest3 kernel: st0: Mode sense. Length 11, medium 85,
WBS 10, BLL 8
Jul 30 17:32:28 conquest3 kernel: st0: Density 0, tape length: 0, drv buffer: 1
Jul 30 17:32:28 conquest3 kernel: st0: Block size: 1024, buffer size: 32768
(32 blocks).
Jul 30 17:32:28 conquest3 kernel: st0: Got tape pos. blk 17832312 part 0.
Thanks in advance for any help
ael
next reply other threads:[~2002-07-30 20:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-30 20:20 ael [this message]
2002-08-01 4:45 ` st.c block limits Kai Makisara
2002-08-01 11:46 ` ael
2002-08-01 13:14 ` Tony Battersby
2002-08-01 15:49 ` Rogier Wolff
2002-08-01 22:51 ` ael
2002-08-01 11:57 ` ael
-- strict thread matches above, loose matches on Subject: below --
2002-08-01 16:06 Bryan Henderson
2002-08-01 16:53 Bryan Henderson
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=3D46F4F4.1090703@ntlworld.com \
--to=law_ence.dev@ntlworld.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.