From: ael <law_ence.dev@ntlworld.com>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: linux-scsi@vger.kernel.org
Subject: Re: st.c block limits
Date: Thu, 01 Aug 2002 12:57:02 +0100 [thread overview]
Message-ID: <3D49220E.3030003@ntlworld.com> (raw)
In-Reply-To: Pine.LNX.4.44.0207310731150.25578-100000@kai.makisara.local
Kai Makisara wrote:
> On Tue, 30 Jul 2002, ael wrote:
>
>
>>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.
>>
>
> The block limits tell the block size limits the drive reports, not limits
> to the amount of data. The driver writes data until the drive tells that
> there is no space. I.e., the driver does not limit the amount of data
> written to the tape. No changes affecting this behaviour has been made for
> a very long time.
>
>
>>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.
>>
>
> Looks like you are at end of tape. I think the 20 GB capacity is
> compressed and not real. This means that the actual amount of data you can
> write on the tape depends on the compressibility of data. 17.8 GB is
> actually not too bad in this case.
>
> Kai
Following up my previous reply where I noted that I had only written 8.8Gb
to a tape with uncompressed capacity of 10Gb, it then seems that the tape
firmware is reporting a maximum drive capacity of ~ 16GB.
And perhaps a real tape limit of 17832312 /2 = 8.9GB which is supposedly on
a 10GB tape : Imation NS-20, specified as 10GB uncompressed. Should I ask
Imation for replacements :-) ?
ael
next prev parent reply other threads:[~2002-08-01 11:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-30 20:20 st.c block limits ael
2002-08-01 4:45 ` 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 [this message]
-- 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=3D49220E.3030003@ntlworld.com \
--to=law_ence.dev@ntlworld.com \
--cc=Kai.Makisara@kolumbus.fi \
--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.