Custom Query (1405 matches)
Results (70 - 72 of 1405)
Ticket |
---|
#44 |
Description |
The table which maps a USB ID to corresponding '-d type' option is hard coded in the source. It should be possible to read this info from a file. This is already implemented for the drive database. |
#45 |
Description |
Debian and Fedora version of smartd provide a '-C, --capabilities' option. If libcap-ng is available and this option is specified, smartd drops unnecessary POSIX capabilities. Debian patch: http://patch-tracker.debian.org/patch/series/view/smartmontools/5.39-3/62_lowcap.patch But the current version of the above patch introduces a regression, see ticket #41 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564876. This should be fixed before we apply this patch. |
#47 |
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? |