Les Mikesell wrote: > On Fri, Aug 24, 2012 at 9:24 AM, <m.roth at 5-cent.us> wrote: >> > I'll step into this again: let's look at the context. >> >> 1. a drive's failed. No conflict. >> 2. 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