Jim, thanks for the great information and war stories.  In a perfect
(supported) world, I would be all in favour (spelling in honor of Gilles) of
supported devices with proper firmware and such.  However, in a homesteading
environment, this is becoming increasingly more difficult if not near
impossible, so new solutions are needed.

From your message, I would highlight the need to do as complete testing as
possible on the solution one implements and to be on the lookout for
anomalies.  The other aspect is try not to push the use of newer very high
performance devices on older systems; it would be a good thing to stay as
closely matched in capabilities as possible.  Alas, as time progresses, this
will also become impossible as newer devices keep appearing and older
devices fail and die.

Denys

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Hawkins, Jim (HP, MPE/iX Lab)
Sent: Friday, September 28, 2007 1:54 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] dat40

Denys & Gilles, 

This may not address every one of your questions but hopefully will help you
understand where I am coming from. 

Ideally a SCSI device driver would abstract the device behavior in such a
way as to render the consideration of the bus to be moot.  As such we do use
the SCSI_TAPE_DM to support DDS/DAT on both NIO and PCI systems as well as
use the SCSI_TAPE2_DM to support "non-DDS" tapes on both also.  We even use
the SCSI_DISK_AND_ARRAY DM with three different HBA families (HVD, LVD, FC).


So a very good question: If the SCSI_TAPE_DM supports DAT24 (DDS-3) on
A/N-Class (via PCI_SCSI_DAM) AND on K-Class (via SCSI_DAM) why does HP
support DAT40 only an A/N-Class?  

In short: testing time. Technically from an MPE standpoint I would be
worried about the device stressing the SCSI_DAM (SE SCSI) driver in new
ways.   This 17+ year old code, firmware and hardware package is SCSI-1
compliant so SCSI-2 and 3 or later devices might do something perfectly
"standard" which it cannot handle.  From a device standpoint I would be
concerned about the operation in narrow/slow mode rather than wide/ultra2 --
timing assumptions in the firmware state machine might be thrown off and
spit out an exception we cannot handle. Finally on the device side there is
the 'shoeshine' problem Denys pointed out. 

So, to get what I think is Gilles root question:  Performance is good so
what more than VSTORE should be done?
Outside of more esoteric stuff like power fail, abortio, and SCSI bus
interruption testing which might be hard to do without special equipment and
software, the biggest problem I can think of off the top of my head would be
related to the 'shoeshine' problem.  That is, even with decent performance,
we might be over stressing the drive or the media such that it causes
premature failure of either and, before that, marginal results.  The
information is likely in the device's internal SCSI Logs (LOG SENSE, LOG
SELECT commands).  Write error and read error counts would be something to
monitor, others might also be helpful.  Historically HP Diagnostics would
return some of this information and, for disks at least HP Predictive would
look at it.   If you don't have access to this information and cannot "roll
you own" then something like a limiting the re-use of media might reduce
risk.  

Denys kind of asked: If SCSI_TAPE2_DM works with Ultrium and DLT why not
DDS? 
Originally the SCSI_TAPE2_DM was forked from SCSI_TAPE_DM -- SCSI_TAPE2_DM
therefore does contain DAT/DDS code circa 1990 which is DDS1 timeframe.   As
part of the original development effort the lab put in special cases for the
HP7980S/SX 1/2" reel tapes and then the 3480 "StorageTek" 1/2 Cartridge tape
devices.  Later code was added for DLT and finally the changes for Ultrium.
However, since the original porting effort no effort has been made to test
the DDS compatibility of this driver. So if you want to use DAT/DDS use
SCSI_TAPE_DM. . . 

Now here's one example of what I have seen go wrong using the SCSI_TAPE2_DM
driver with the "wrong" device.   Only a year or two ago a customer was sold
some DLTs with some firmware which was not tested with MPE.  This device
worked well enough such that the customer did not think immediately that it
was a lemon.  Unfortunately the way that the driver was trying to do things
was incompatible with the way the Device expected and we eventually went off
into the weeds far enough caused a System Abort.  Where we ended up in the
code was so weird it took me several days of effort to notice that the
SCSI_TAPE2_DM driver, unable to recognize the device as a DLT, was actually
trying to handle this DLT as a DDS (or at least its 15+ year old concept of
DDS). "Doh"! The official HP firmware was loaded.  Problem solved.  The very
fact that the driver & device match was "close enough" made it work for a
while but NOT well enough in every case. 

So I this helps you understand why I tell folks "Not supported by HP" even
when you say you've had good luck. 

Best Regards,

Jim 

P.S.  I hadn't considered running the DAT40 with only DAT24 media.
Interesting, could reduce the problem of shoe-shining. Still an newish &
untested device talking to a very old HBA. . . 
 

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *