Les Mikesell wrote:
On Fri, Aug 24, 2012 at 9:24 AM, m.roth@5-cent.us wrote:
I'll step into this again: let's look at the context.
- a drive's failed. No conflict.
- a server's failed, and you want something off one of its disks: a) you put it in a hot swap bay, and aren't rebooting the server - you are going to be manually mounting it, so no conflict b) you need to replace the server in -10 sec: you throw the
drive(s) into a standby box, and either i. it's got partitions labelled /boot and /; fine, you *want* it to use those ii. you want a drive from another disk on that failed system: no problem - see 2.a. c) you have a system without hot swap bays, and you install the drive from the failed system, and then you do have to power up; this is the only case I can think of, off the top of my head where you have a collision. In this case, you need linux rescue, and relabel.
So, where's the big issue with std. labels?
You power down, add some disks that you want to re-use. Maybe even add a controller. Just because a bay looks like you can hot-swap doesn't mean it is a good idea if you don't have to. You boot up.
Okayyyy... We differ, here - I've come to adore hot-swap bays, and hate having to take a system apart to add another drive.
Reused disks - I reformat them, usually in a hot swap bay.
Of course, I *do* have some additional concerns - I have to worry about PII and HIPAA data that may, *possibly*, be on the drives.
When the label scheme was first rolled out, the machine wouldn't boot if it found a duplicate. Now it will pick one. Possibly the wrong one. As you might when you do a rescue boot for the relabel since you won't know which controller is detected first.
But you can do a rescue, mount, and look at what's on what the controller found.
mark