Solved Forcing /dev/ses0 to /dev/ada6?

G

Griffinhart

So I had a problem: one of my disks had disappeared. This made me supremely uncomfortable, what with it being part of a 3-disk raidz1.

Power off, check SATA and power connections, saw nothing wrong, powered back on and hoped for the best.

Success! The disk that was gone showed up again!

...Except that now, a different disk, in the same pool, was gone. And now that pool, instead of being degraded, is faulted. Grmph.

Code: 
$ sudo camcontrol devlist
Password:
<Hitachi HDS722020ALA330 JKAOA3EA>  at scbus1 target 0 lun 0 (ada0,pass0)
<Hitachi HUA723020ALA641 MK7OA840>  at scbus2 target 0 lun 0 (ada1,pass1)
<ST2000DM001-1CH164 CC24>  at scbus3 target 0 lun 0 (ada2,pass2)
<ST2000DM001-1CH164 CC24>  at scbus4 target 0 lun 0 (ada3,pass3)
<WDC WD20EADS-11R6B1 80.00A80>  at scbus6 target 0 lun 0 (ada4,pass4)
<WDC WD20EARX-00PASB0 51.0AB51>  at scbus7 target 0 lun 0 (ada5,pass5)
<AHCI SGPIO Enclosure 1.00 0001>  at scbus8 target 0 lun 0 (ses0,pass6)
So, yeah. Instead of having /dev/ada0 through /dev/ada6, I have /dev/ada0 through /dev/ada5 + /dev/ses0.

ada4 and ada5 correspond to the two disks that are currently online in my faulted pool (ada1-3 correspond to disks in a different pool, and ada0 is the system/boot disk), so by process of elimination, ses0 is the missing disk.

Is there any way to force /dev/ses0 back to being /dev/ada6 (or really, ada anything - I'd actually prefer it to be /dev/ada5, like how it was before all this awfulness), or is this a case of "replace the hardware"?

(Which would be really strange, because this disk was entirely fine up until I power-cycled my machine trying to diagnose an issue with a different disk.)

I don't even know what ses is. SCSI Enclosure Device, apparently? Why would it show up as that? (Possibly because it was originally a Western Digital external HDD whose casing I shucked so I could slip it into my FreeBSD server?)
 
Griffinhart said:
Is there any way to force /dev/ses0 back to being /dev/ada6 (or really, ada anything - I'd actually prefer it to be /dev/ada5, like how it was before all this awfulness), or is this a case of "replace the hardware"?
Click to expand...
ses(4) is the enclosure services. It is probably the disk backplane in your system. It would be very unlikely for it to be associated with any specific disk drive. You probably never noticed it before.

# camcontrol rescan all will re-scan all of the disks without needing to power cycle or reboot.

# glabel label is your friend. It will let you assign your own names to drives (which you will then find under /dev/label).

(Which would be really strange, because this disk was entirely fine up until I power-cycled my machine trying to diagnose an issue with a different disk.)
Click to expand...
This sort of thing is normally a cable problem, a power supply problem, or overlooking something while unplugging/replugging. Since you don't mention what sort of system this is, I don't know if it has a hot-swap backplane or not.
 
No, no hotswap or backplanes. All the disks (except the boot disk) are connected directly to the motherboard.

I've already swapped the SATA cable for a fresh one (a new one, in fact; I just happened to have a spare, still-in-plastic cable lying around).

I wasn't aware of rescan. Thanks for that one!
 
In the end, it was PEBCAK. I was poking at the wrong disk (I could've sworn I read the serials correctly!); /dev/ses0 is the PCI SATA controller I have. Switching out the SATA cable for the right disk has brought it back online and the faulted pool is in the middle of a scrub as I type this.
 
You must log in or register to reply here.
Back
Top