Opened 15 years ago
Closed 15 years ago
#47 closed defect (fixed)
strange disk count when dealing with external cciss arrays
Reported by: | anonymous | Owned by: | somebody |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | smartctl | Version: | 5.38 |
Keywords: | Cc: | zoniguana |
Description
I have 2 MSA arrays off of my system, each with 28 disks. I also have the internal smart array on my system, with a variable number of disks.
When I run my smartctl, I do have to enter -d cciss,{disk_number} /dev/cciss/cXd0. This is expected and makes sense to me, somewhat.
Running smartctl -d cciss,7 gets me the 8th disk in the array from controller 0, as I understand it (cciss,0-7 all return good values). This makes sense to me, too.
The next controller starts the weirdness.
Running smartctl -d cciss,28 /dev/cciss/c1d0 gets me the 28th disk of the first external array (I think). I get values for cciss,0-28, which means I get 29 values from 28 disks.
Then, running smartctl -d cciss,29 /dev/cciss/c2d0 gets me the 28th disk of the second external array (again, I think). I get values for cciss,0-29, meaning I get 30 values for 28 disks.
My assumption is that some of these are actually reporting on, say, the bus of the array, not just the disks. So, how can I know what is disk response, and what isn't?
Change History (2)
comment:1 by , 15 years ago
Cc: | added |
---|---|
Priority: | major → minor |
comment:2 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
So, from the above, I assume that it is working as intended...
An update to this:
There is a failed disk on c1. On another system with similar setup, c1 goes to 29, just as c2 does.
So, it would appear that,if a disk has failed, smartctl won't touch it. Doesn't report any errors, it just seems to skip that failed disk.
Likewise, in parsing through the -a output, I have found that two of the devices in the list are the actual buses (they appear as Device: COMPAQ PROLIANT, as compared to COMPAQ {some disk model}.