- Community Home
- >
- Storage
- >
- Entry Storage Systems
- >
- Disk Enclosures
- >
- Model 20
Disk Enclosures
1756997
Members
2329
Online
108858
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2004 09:06 AM
08-31-2004 09:06 AM
I have an old K220 800 system with a disk array Model 20 (A3232A) that I have recently reassembled the hardware (it had been out of service for about 5 years) and, then after the system was up and running, I upgraded the OS to 10.20 (I know how old the system is but it is all that I have). I have applied the OS patch PHCO_23261 (and a few other patches). The problem that I am having is that it takes an exceptionally long time to read and write (including moving and deleting) to the disk array. I believe that all of kernel parameters tuned correctly. Can anyone out there dust off your memory cells and tell me why the disk array access would be so slow? Also, the SCSI cable from the system goes to the disk array SCSI-B and then terminated. There is also a SCSI-A but there is nothing plugged into it. Should the system connect to the disk array SCSI-A and then a SCSI jumper cable to SCSI-B and then terminate???
Thank you
David
Thank you
David
Solved! Go to Solution.
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2004 05:20 PM
08-31-2004 05:20 PM
Solution
Sounds like you have a NIKE (aka clariion) array. It has been a while....
There are two controller (A and B) on a model 20. When you bind a lun, you assign it to one of the two controllers. It is possible that the LUNs were bound to Controller A. You can move the cable to SCSI-A, and do a full ioscan (#ioscan -funC disk) to see if new devices are created. (then #insf to actually build the device files)
NIKE arrays, if configured properly, will allow LUNs to be "failed over" (autotresspass is the term they use) to the other controller.
Best bet is to connect a dumb terminal, or a laptop running a terminal emulator to the NIKE, and see how the array was configured.
There are some tweaks that can be made to the cache settings, etc.
Usually when I saw poor performance, it was due to SCSI errors. Check the output of the dmesg command to see if you are receiving SCSI lbolt errors. These result from a bad terminator, or bad cable, and sometimes from a bad host SCSI card.
Hope this helps. If you get the terminal connected to the NIKE, let me know. I can probably dig up some documentation....
-tjh
There are two controller (A and B) on a model 20. When you bind a lun, you assign it to one of the two controllers. It is possible that the LUNs were bound to Controller A. You can move the cable to SCSI-A, and do a full ioscan (#ioscan -funC disk) to see if new devices are created. (then #insf to actually build the device files)
NIKE arrays, if configured properly, will allow LUNs to be "failed over" (autotresspass is the term they use) to the other controller.
Best bet is to connect a dumb terminal, or a laptop running a terminal emulator to the NIKE, and see how the array was configured.
There are some tweaks that can be made to the cache settings, etc.
Usually when I saw poor performance, it was due to SCSI errors. Check the output of the dmesg command to see if you are receiving SCSI lbolt errors. These result from a bad terminator, or bad cable, and sometimes from a bad host SCSI card.
Hope this helps. If you get the terminal connected to the NIKE, let me know. I can probably dig up some documentation....
-tjh
I learn something new everyday. (usually because I break something new everyday)
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP