From owner-freebsd-scsi Sat Apr 25 21:25:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA11914 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:25:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA11909 for ; Sat, 25 Apr 1998 21:25:43 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id VAA29111; Sat, 25 Apr 1998 21:25:18 -0700 Date: Sat, 25 Apr 1998 21:25:18 -0700 From: Matthew Jacob Message-Id: <199804260425.VAA29111@feral.com> To: dkelly@hiwaay.net, freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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