Disk Arrays
cancel
Showing results for 
Search instead for 
Did you mean: 

I/O bad request.

SOLVED
Go to solution
Jeffrey F. Goldsmith
Super Advisor

I/O bad request.

I have an L2000 with HPUX 11.0 and a Surestore E Disk Array 12H.
One of my programers told me that they are getting some errors in their log and think that we might have a bad disk.
I am going to attach the document.
I would like to know if there are any tests that I could run on my AutoRAID to see if if there are any problems with any of the hard drives?
Thanks.
7 REPLIES
Eugeny Brychkov
Honored Contributor

Re: I/O bad request.

Jeff,
please attach zipped outputs of
arraydsp -a
logprint -t All
and then looking to the output of these commands we'll be able to tell you how 12h feels. If it will appear to feel fine then look for bad cable, terminator or malfunctioning SCSI card. Check patches also (minimum Sep 2002 patch bundles should be installed)
Eugeny
Jeffrey F. Goldsmith
Super Advisor

Re: I/O bad request.

root: /home/root ==> arraydsp -a
Usage: arraydsp [-l [LUN] | -d | -c | -s | -v | -h | -a |
-r stime etime | -m stime etime [int]]
[-V] [-?]

arraydsp {-i | -R} [-V] [-?]

root: /home/root ==> logprint -t All
Invalid record type - 'All'
Usage: logprint [-s ] [-e ]
[-t ]
[-d ] [-a ]

A. Clay Stephenson
Acclaimed Contributor

Re: I/O bad request.

First do an arraydsp -i and that will give you the "array_id" that the commands expect.
If it ain't broke, I can fix that.
A. Clay Stephenson
Acclaimed Contributor

Re: I/O bad request.

I rather doubt that you have a bad disk (or at least a bad LOGICAL disk) because the 12H should have hidden all its physical disk problems from the application. I woulld check syslog for problems because you should have been seeing tons of "LBOLTS". It's possible that you have a corrupt filesystem rather than disk (logical or physical) problems.
If it ain't broke, I can fix that.
Jeffrey F. Goldsmith
Super Advisor

Re: I/O bad request.

Here is the arraydsp -a
A. Clay Stephenson
Acclaimed Contributor
Solution

Re: I/O bad request.

All of that looks good but you need to do a logprint to display more detailed data. It APPEARS that your 12H is fine although you have essentially allocated all you space - which will reduce performance. You still have "Active Hot Spare" enabled so that as soon as a disk fails the array will begin an automatic rebuild. All your physical drives are up so this does not appear to be a problem.

I would do a vgdisplay -v on your VG's and note each PV which makes up the VG. Next do a pvdisplay /dev/dsk/cXtYdZ and note the IO Timeout on each 12H LUN device. If you used the default 30 seconds then you should increase that to 120-180 seconds using pvchange.

This will ONLY apply if you see IO Timeout messages in syslog. That's really where you need to be concentrating. You may (probably) have no problems at all with the 12H.
If it ain't broke, I can fix that.
Eugeny Brychkov
Honored Contributor

Re: I/O bad request.

Agree with Clay. In addition I would say that 12h is configured in the best way.
Please attach logprint and /var/adm/syslog/syslog.log zipped. Logprint will help us to identify if array is experiencing any problems, syslog - if OS does or not. If both will show clean then I would say that your application is generating problems. Why? Maybe because it reads data which can not understand?
Eugeny