4

I have a Dell PE1950 running the latest OpenSolaris, connected to a Dell MD1000 enclosure with 15 disks in it. I am not using PERC to control the disks, instead I use a simple SAS 5/E (LSISAS1068) controller that exposes the raw disks so we can use ZFS RAID instead of hardware RAID.

It all works very well, but I have one worry about the time when we need to replace one of the disks for any reason. When I used PERC, it had the capability of turning the error led on the disk if something went bad, and also gave me a way to manually blink the led should I want to physically locate it for any reason.

However, now when I use the plain SAS connection it looks like these capabilities are inaccessible, and the only way to identify the disk is by guessing what it is from the device number (which I find very risky), or shutting down the whole system, pulling the disks one by one and comparing the serial#.

Both options are, of course, not acceptable. I would like to know if there is any way that I could manually operate the LEDs on Solaris. I have searched a lot and found that on Sun servers this can be done using the cfgadm tool, but when I tried to run the same commands on my server it failed, saying the hardware specific feature is unavailable.

I also tried using the LSIUtil command, but it doesn't seem like it supports this functionality either.

Is there any way I could visually identify the disks?

Improve this question
5
  • 2
    Have a look at this blog entry from 2008: blogs.sun.com/eschrock/entry/… It's from July 2008 so it's possible that that has been integrated into OpenSolaris.
    – gm3dmo
    Jan 2, 2010 at 11:35
  • davery: Thanks, this helps a lot. I was able to view some information about the MD-1000 using this command, including the SAS address of each of the bays. Unfortunately it doesn't drill down to the disk level like in the blog example, so I still don't know the disk ID or serial# of each of the bays. I think I could cross reference this with the prtconf output to do have this mapping. Also, I couldn't figure how to use the command to change to turn on the LED. Not perfect, but definitely better than nothing.
    – sagi
    Jan 2, 2010 at 15:12
  • Ok, here is another piece of the puzzle: blogs.sun.com/olympus/entry/disks_disks_everywhere That may only be valid for that M9000 type server though.
    – gm3dmo
    Jan 2, 2010 at 19:44
  • Just out of interest, does anything happen to the LED if you do a cfgadm unconfigure on the disk?
    – gm3dmo
    Jan 2, 2010 at 20:29
  • davey: none of the cfgadm -x commands are working, and it seems like cfgadm unconfigure doesn't do anything to these disks. They stay in "configured" mode even after I ran the command, and fmtopo still reports that the LEDs are off after I ran it (can't easily visually verify it because the server is at a remote location).
    – sagi
    Jan 3, 2010 at 0:22

2 Answers 2

Reset to default
1
search for MegaCli tool for solaris [ you can find it at lsi's webpage ] and use syntax: megacli -PdLocate -stop -physdrv[1:2] -a0 note: i have only perc controlers and it works fine with them, as i understand same tool can be used with non-raid controlers, but i might be wrong. your comment telling if it works or not is welcome.

if that does not work - during maintenance window take whole system down, and label all the caddies with hard drives' serial numbers.

Improve this answer
2
  • Thanks for the suggestion but MegaCli does not work with the plain SAS controller. It worked when I used a PERC, but I had to switch to the SAS 5/E because PERC does not have a JBOD mode.
    – sagi
    Jan 2, 2010 at 15:08
  • Sounds like the labeling of the caddies with the serial # is the best bet, as I know of no way to reliably tell which is which. Just make sure it's a label that you can replace in case the drive needs to be switched out, unless you don't care about how neat it looks.
    – Bart Silverstrim
    Jan 11, 2010 at 13:07
0

OK, I admit off the bat that this is a FUD answer and so I'd ask people just call me stupid rather than taking points off, but...

If you're using ZFS I believe that you can take a disk offline without fear of the entire raid set going funny, so (actually you might not need to take it offline first, i don't really know):

Can you not just run dd on the physical device (and output it to /dev/null). basically doing a massive read and causing the disk access light to be fully on? This does assume that you have blinky access LEDs for each physical disk.

Improve this answer
2
  • Sure I can take a disk offline without damaging the entire array, but I am afraid that I will take the wrong disk offline because I won't be able to identify the correct disk, and then I will have two failed disks instead of one and the array will be damaged. The dd method is no good because if the disk is damaged there is no guarantee that dd will be able to access it at all, and on production server such as this all the disks are always working hard so the activity light will probably be on for all of them anyway.
    – sagi
    Jan 6, 2010 at 14:46
  • I don't know if you'd have to take it offline before doing a DD read -as you're not using it for anything but causing data access, the data on the disk changing (i think) shouldn't matter. Sadly, its always busy, it won't actually help. (and I was thinking about doing it disk at a time BEFORE any failure -but as you say, it wont help). Actually, if all the drives are too busy then surely if a drive fails and gets taken offline (i think automatically by ZFS when the pool degrades) then you might be able to identify it due to its lack of access. certainly not a perfect situation.
    – BuildTheRobots
    Jan 6, 2010 at 20:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .