Date: Thu, 9 Apr 1998 23:23:29 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: grog@lemis.com Cc: ip@mcc.ac.uk, scsi@FreeBSD.ORG Subject: Re: compression on Exabyte 8700LT? Message-ID: <199804100523.XAA10189@panzer.plutotech.com> In-Reply-To: <19980410112408.01873@freebie.lemis.com> from Greg Lehey at "Apr 10, 98 11:24:08 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[ lists trimmed to just -SCSI, where this thread really belongs ]
Greg Lehey wrote...
> On Thu, 9 April 1998 at 16:27:31 +0100, Ian Pallfreeman wrote:
> > I've recently acquired another Exabyte drive, an 8700LT. This drive claims to
> > be able to write 10Gb to a 112m tape in compressed mode, but I'm getting just
> > the 5Gb I'd expect uncompressed.
> >
> > ...
> >
> > FreeBSD 3.0-CURRENT #9: Thu Apr 9 16:06:09 BST 1998
> > ip@lurch:/usr/src/sys/compile/LURCH
[ ... ]
> I think there's a general problem with tape compression under
> -CURRENT. A few months back, I used to be able to back up a complete
> 8 GB on my DDS-2 drives, but now I've done some testing and found it
> gives up somewhere round 3.4 GB. I don't understand that, since the
> native tape capacity is 4 GB.
It does sound sort of like compression is off.
> -CURRENT people: I'm using the old SCSI driver. The tape is set to
> start up in compressed mode, and the DC LED is illuminated all the
> time. This looks to me as if something in the driver is explicitly
> disabling compression, or just possibly that the driver is guessing
> the size of the tape and stopping (with EIO) when it reaches this
> point.
That certainly sounds odd. I haven't explored the -current tape
driver enough to know which might be the case. Since the data comrpession
light is on, I'd guess that compression really is enabled...
> The other point is that it's still returning EIO. I know there's been
> some discussion about this before, and ISTR that it was inconclusive
> ("that's the way our grandfathers did it"). While looking at the
> problem, I came across a program I wrote in my BSD/OS days back in
> 1992, and I note that even then BSD/OS returned ENOSPC when it got to
> the end of the tape. This makes a whole lot more sense, and it
> obviously seems to have withstood the test of time. How about it?
The CAM tape driver (at least the one in our development tree)
returns ENOSPC when it reaches the end of a tape. dump and restore in the
CAM tree have been patched to recognize that as an end of tape signal.
> Would I get an improvement on either of these points if I installed
> CAM? I know that CAM can't handle compression switching yet, but can
> it do compression if it's enabled on the drive?
Wait until the next CAM snapshot, and I think both of these will
improve for you. You will be able to tell from mt(1) whether your drive is
capable of compression, and if so, whether it is enabled. If it is
enabled, mt will tell you which algorithm is in use. You can also enable
and disable compression. I have successfully tested it on two different
Archive Python drives (DDS-1 and DDS-2), a Sony SDT-5000, an Exabyte 8200,
Exabyte 8500 and an Exabyte Eliant. I believe it should work with most any
drive. (Well, okay, I haven't tried it with any Tandberg drives...)
As far as when the next snapshot will be out...I believe Justin
wants to get the BusLogic driver solidified before he makes the snap. I
think the driver is in good shape now, but I would be foolish to make
any promises on when the snapshot will come out.
Ken
--
Kenneth Merry
ken@plutotech.com
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?199804100523.XAA10189>