>> #1. Map the physical drive slots to how they show up in FBSD so if a >> disk is removed and the machine is rebooted all the disks after that >> removed one do not have an 'off by one error'. i.e. if you have >> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >> missing ada8 drive and the next drive (that used to be ada9) is now >> called ada8 and so on... > >How do you do that? If I'm in that situation, I think I could find the >bad drive, or at least the good ones, with diskinfo and the drive serial >number. One suggestion I saw somewhere was to use disk serial numbers >for label values.The term FreeBSD uses for this is called "wiring down" or "wired down", and is documented in CAM(4). It's come up repeatedly over the years but for whatever reason people overlook it or can't find it. Here's how you do it for Intel AHCI (and probably others like AMD), taken directly from my /boot/loader.conf -- # "Wire down" device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at="ahcich0" hint.scbus.1.at="ahcich1" hint.scbus.2.at="ahcich2" hint.scbus.3.at="ahcich3" hint.scbus.4.at="ahcich4" hint.scbus.5.at="ahcich5" hint.ada.0.at="scbus0" hint.ada.1.at="scbus1" hint.ada.2.at="scbus2" hint.ada.3.at="scbus3" hint.ada.4.at="scbus4" hint.ada.5.at="scbus5" IMPORTANT: The device names/busses/etc. are going to vary depending on each person's setup, controller, etc.. Proof of this is in a post from Randy Bush, where I helped him off-list with this task and he figured out the remaining bits by himself for his hptrr(4) controller: http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014522.html You can use labels if you want, but I prefer to just have statically assigned device names regardless of a bay being populated by a disk or not. That's my preference. Other people like labels and that's fine -- I just can't stand the utter mess that is labelling on FreeBSD, sans GPT labels. And finally, touching /boot/device.hints is wrong. Do not do this. Ever. This file is actually "managed" by either mergemaster or installkernel/installworld (I forget which). Use /boot/loader.conf for any hint overrides/adjustments. Leave /boot/device.hints alone. -- | Jeremy Chadwick jdc at koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
On Thu, 24 Jan 2013, Jeremy Chadwick wrote:>>> #1. Map the physical drive slots to how they show up in FBSD so if a >>> disk is removed and the machine is rebooted all the disks after that >>> removed one do not have an 'off by one error'. i.e. if you have >>> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >>> missing ada8 drive and the next drive (that used to be ada9) is now >>> called ada8 and so on... >> >> How do you do that? If I'm in that situation, I think I could find the >> bad drive, or at least the good ones, with diskinfo and the drive serial >> number. One suggestion I saw somewhere was to use disk serial numbers >> for label values. > > The term FreeBSD uses for this is called "wiring down" or "wired down", > and is documented in CAM(4). It's come up repeatedly over the years but > for whatever reason people overlook it or can't find it.I was aware of it, it just seems like there ought to be a better way to identify drives than by messing with the hardware configuration. Something more elegant, less tied to changing the hardware configuration of the host. Assigning the drive serial number as a label, for example.
On Thu, Jan 24, 2013 at 5:40 PM, Jeremy Chadwick <jdc at koitsu.org> wrote:>>> #1. Map the physical drive slots to how they show up in FBSD so if a >>> disk is removed and the machine is rebooted all the disks after that >>> removed one do not have an 'off by one error'. i.e. if you have >>> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >>> missing ada8 drive and the next drive (that used to be ada9) is now >>> called ada8 and so on... >> >>How do you do that? If I'm in that situation, I think I could find the >>bad drive, or at least the good ones, with diskinfo and the drive serial >>number. One suggestion I saw somewhere was to use disk serial numbers >>for label values. > > The term FreeBSD uses for this is called "wiring down" or "wired down", > and is documented in CAM(4). It's come up repeatedly over the years but > for whatever reason people overlook it or can't find it. Here's how you > do it for Intel AHCI (and probably others like AMD), taken directly from > my /boot/loader.conf -- > > # "Wire down" device names (ada[0-5]) to each individual port > # on the SATA/AHCI controller. This ensures that if we reboot > # with a disk missing, the device names stay the same, and stay > # attached to the same SATA/AHCI controller. > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > # > hint.scbus.0.at="ahcich0" > hint.scbus.1.at="ahcich1" > hint.scbus.2.at="ahcich2" > hint.scbus.3.at="ahcich3" > hint.scbus.4.at="ahcich4" > hint.scbus.5.at="ahcich5" > hint.ada.0.at="scbus0" > hint.ada.1.at="scbus1" > hint.ada.2.at="scbus2" > hint.ada.3.at="scbus3" > hint.ada.4.at="scbus4" > hint.ada.5.at="scbus5" > > IMPORTANT: The device names/busses/etc. are going to vary depending on > each person's setup, controller, etc.. Proof of this is in a post from > Randy Bush, where I helped him off-list with this task and he figured > out the remaining bits by himself for his hptrr(4) controller: > > http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014522.html >This wiring down is not sufficient to address all the problems with drive renumbering. For instance, add an additional ahci controller, and potentially all your drive names change again. Or not, depending on how the devices are enumerated. This is not the only problem. Take all the disks out, put them all back in, do they all have the same names? Unlikely, since their name is now derived from the controller and port they are plugged in to. Any changes, and the device name changes. Using GPT labels is easy to do, and provides a cast iron guarantee that your disk will not EVER be mistaken for a different drive. I put a GPT label on the drive, and then write it in permanent marker on the top of the drive and on a sticky label that is stuck on the front of the chassis. The disk label never changes in its lifetime, so you only get issues if you insert a drive without labelling it first. Cheers Tom