Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> I happen to do DRBD over LVM which I like however there is documentation on doing both... A > LVM -> DRBD -> LVM (however little I may understand of why you would want this) Thank you as well, Jake. That would work (since LVM solves this problem by tracking physical drives by metadata rather than by name); however, I would prefer to eliminate the extra layer of LVM that is only offering me drive management, which I can do using other tools. For example, here is what I am considering: I have 26 slots labeled a - z on each server. To simplify management, I want to replicate the drive in slot a on server 1 to the one in slot a on server 2, and so forth. If the drive failed in slot a I would simply like to replace it and have everything magically work. Theoretically, this could be accomplished; but, apparently, mapping SAS ports (each slot would be a different SAS port) in linux has never worked reliably. The only way to reliably identify a drive is by its ID number or serial number. So, I would use udev to map a drive by serial number (which conveniently is printed on the label) to /dev/sda (representing slot a). I would configure DRBD using /dev/sda. In the event of the failure of sda, I would pull the drive, replace it, and update udev with the serial number of the replacement drive. While this strategy does require the manual mapping of serial numbers to slot identifiers, it does eliminate the overhead of having another layer of LVM while still eliminating random device naming. Furthermore, since most drives (except Toshiba drives apparently) report their serial numbers or WWNs to the OS is very easy to get the serial number from the label during installation. Can anyone poke any holes in this? I will be happy to post complete set of instructions as well as the results of testing when I get my hardware next month. Ted Young