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. . .
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf Of Denys Beauchemin
Sent: Thursday, September 27, 2007 8:09 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] dat40
I did not have much time at all to respond to my friend Christian's query so
I just gave him two alternatives for connectivity with the most likely
working one being the first one. I even specified the type cable to get.
I figured that if he was going to look at the second one, Christian would
come back with more questions and during the detailed analysis of how to
configure it, the issue of lack of drivers for a DDS drive on an HP FWSCSI
would show up. I surely do not want to disagree with Jim, however, there
are 2 drivers for tape drives: SCSI_TAPE_DM and SCSI_TAPE2_DM, just as there
are 2 drivers for disk drives: SCSI_DISC_DM and SCSI_DISK_AND_ARRAY_DM.
The SCSI_TAPE_DM driver is listed for all SCSI-attached DAT drives and these
would all be attached through the SE (LVD on N-class) SCSI channel. The
SCSI_TAPE2_DM is listed for the DLT devices, I have also made it work with
LTO devices. That driver would be used for all SCSI tape drives attached
through the FWSCSI channel or what is known as HVD (High Voltage
Differential).
The way I see it, the driver is dependent on the SCSI HBA. If the HBA is a
wide SCSI, differential or low voltage, one use the SCSI_TAPE2_DM driver for
tape drives and SCSI_DISK_AND_ARRAY_DM driver for disk drives. If the HBA
is a narrow SCSI, one use SCSI_TAPE_DM driver for tape drives and
SCSI_DISC_DM for disk drives.
One can look at the IODFAULT file and scan the generic configuration at the
end of the file.
So, my thought was that if one uses the SE SCSI channel for a DAT40, one
would use SCSC_TAPE_DM as the driver. I know that will work, but I also
know that the DAT40 is much faster than the channel and may suffer shoeshine
mode because of that. The faster FWSCSI channel would be preferable as it
could perhaps feed the tape drive faster, but there one would have to use
the SCSI_TAPE2_DM driver. My belief is that it makes no difference to the
SCSI driver that a DAT40 is connected on that channel since using SCSI hides
the device behind a known set of generic commands.
I seriously doubt one could boot from such an arrangement, but as a data
backup it has much to offer. Of course, testing is key.
And please, let's not use the term "supportability" when we talk about
devices on the HP3000, that makes me laugh uncontrollably since 11/14/01.
Denys.
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Hawkins, Jim (HP, MPE/iX Lab)
Sent: Wednesday, September 26, 2007 7:47 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] dat40
(top post warning).
Of Denys two suggestions the 50-68 cable to an SE-SCSI HBA is more likely to
provide a basic connection. The HVD/LVD converter would not work on k-Class
as there are actually some driver restrictions in the NIO F/W SCSI HBA
driver that prevent one from configuring a DDS as connected to a A28696A HBA
bus (at least as far back as 6.5).
At the same time "connect ability" does not mean "advisability" and never
"supportability".
o We didn't test the DAT40 on S900/NIO systems because its peak I/O
bandwidth (6.0 MB/sec Asynchronous) was projected to exceed the capabilities
of the SE-SCSI HBA (technically 5.0 Megabytes/sec but really closer to 4
MB/S). Historically it is not a good idea to run tapes at slower than
rated speed as it causes the tape to drop from streaming mode into
start/stop mode and excessive wear and/or bad performance result. Many tape
drives do implement variable speed streaming but it wasn't clear that the
DAT40 was one.
o We never certified any LVD-SCSI interface peripherals on the NIO-SE-SCSI
HBA. Though all Wide LVD devices are technically supposed to be able to RUN
(READ/WRITE/REWIND) narrow & SE-SCSI it is never advisable depend upon
manufacturer actually testing all device functionality in such a hobbled
mode. Additionally newer devices may spit out "SCSI Standard" information
that very old drivers will choke on.
o No idea what the PDC would do if you tried to boot from a CSLT on this
device. . .
This means that DAT40 is NOT supported by HP via SE-SCSI on S900 NIO systems
(9x8,9x9,99x & earlier). Works fine and is supported by HP on A/N-Class.
So, I'd advise you only use this kind of set-up to write data you are
willing to lose ;-)!, OR at least make sure your back-up application vendor
is willing to support you. YMMV. . .
Jim Hawkins
MPE/iX I/O Architect
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Denys Beauchemin
Sent: Wednesday, September 26, 2007 12:32 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] dat40
Hello Christian, long time.
I believe the DAT40 is an LVD device which would require you to connect it
via a 68 to 50 pin cable with high-bit termination or to a 68 bit SCSI port
on the 3000 using a converter to allow you to switch from HVD (HP3000) to
LVD or SE (DAT40).
Denys
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Christian Scott
Sent: Wednesday, September 26, 2007 1:20 PM
To: [log in to unmask]
Subject: [HP3000-L] dat40
Importance: High
Hi,
I need to find out if I can connect a dat40 on a hpe3000 k-class server, if
so what are the step involve.
Thanks,
Christian Scott
VP - Development & CTO
201 Rue Laurier Est
Suite 630
Montréal, Québec
H2T 3E6
Tel: 514-273-0008 x118
Fax: 514-273-0199
Email: <mailto:[log in to unmask]> [log in to unmask]
Web: <http://www.softvoyage.com/> www.softvoyage.com
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
