Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Apr 1998 21:25:18 -0700
From:      Matthew Jacob <mjacob@feral.com>
To:        dkelly@hiwaay.net, freebsd-scsi@FreeBSD.ORG
Subject:   Re: does CAM do this?
Message-ID:  <199804260425.VAA29111@feral.com>

next in thread | raw e-mail | index | archive | help
>From owner-freebsd-scsi@freebsd.org  Sat Apr 25 21:19:26 1998
>Sender: owner-freebsd-scsi@freebsd.org
>X-Loop: FreeBSD.org
>
>Matthew Jacob writes:
>> >        What is the blocksize of the current tape record?
>> 
>> Unless you're tape drive is clairvoyant, you can't  know that
>> until you read the record (or attempt to).
>
>And that's apparently what the SGI Irix "mt blksize" command does.
>Additionally it reports the min and max blocksize supported, and the
>"recommended" blocksize SGI's utilities will use unless instructed
>otherwise, or they inherit a blocksize from the device. Yes, I've seen a
>number of tar tapes with 512 byte blocks (they didn't know), and have
>one source that likes to write 1M blocksize (he thought it would be 
>faster and save space on the tape).
>

No no no no. Block Min/Block max is *not* the same as  variable
blocksize. It just establishes min/max for *fixed* blocks.


>Unless I've messed up here, my "ARCHIVE Python 28388-XXX 4.CM" will 
>read a compressed tape with no way of me knowing that it is doing so. 

That's  not the same as blocksize.

>While an enhanced "mt status" could query many tape drives and report 
>on current tape position, it would be very nice if there was a way to 
>report if the tape was written using a hardware compression method.

Sometimes you can tell, sometimes not. It depends partly on whether
or not the density code reflects compression (getting to be less
and less the case). I believe, off the top of my head, there are
a couple of other clever ways to determine this, none of which is
guaranteed to work on all tape devices. However, considering that
the number of distinct SCSi tape devices in the world is probably
less than a hundred, you'd think that this could be scoped out.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804260425.VAA29111>