Date: Mon, 25 Feb 2013 10:44:27 -0600 From: Karl Denninger <karl@denninger.net> To: Tom Evans <tevans.uk@googlemail.com> Cc: Jeremy Chadwick <jdc@koitsu.org>, freebsd-stable@freebsd.org Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD Message-ID: <512B94EB.30201@denninger.net> In-Reply-To: <CAFHbX1KsWa1JwvU0724owTBxV3ko5QQv4=3pKPyzeHvQBXL1qA@mail.gmail.com> References: <20130124174039.GA35811@icarus.home.lan> <CAFHbX1KsWa1JwvU0724owTBxV3ko5QQv4=3pKPyzeHvQBXL1qA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/25/2013 8:31 AM, Tom Evans wrote: > On Thu, Jan 24, 2013 at 5:40 PM, Jeremy Chadwick <jdc@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 > Listen to this man. Either do it in gpart or do it with glabel (depending on where you want it to show up); once done the drive will always have the same name in the device tree no matter what slot it shows up in. Then stick that label on the front of the drive carrier, and you never have this problem. Do that or suffer. Your choice. -- -- Karl Denninger /The Market Ticker ®/ <http://market-ticker.org>; Cuda Systems LLC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512B94EB.30201>