On Tue, Mar 18, 2008 at 19:25:57 -0700, agenkin AT gmail DOT com wrote: [...]
> Perhaps I wasn't clear, I'll try to restate the problem. :) > > We have thirteen drive bays with removable SATA disks in a box used > for backups. The bays are marked 1 through 13, and mount to /backup/ > drive01 .. drive13. Sometimes we replace some of the disks with new > ones (e.g. to store the old ones for long-term off-line backups), and > we want the replaced disk accessible at the same mount point as the > old disk. The newly inserted disks will have a different UUID, and, > should we use UUIDs, the operation will require reconfiguring the host > to mount the new drives, which is a hassle. > > In essence, we would like to be able to address partitions like it's > done in a BSD-derived Unix. For example, in Solaris /dev/dsk/c1t4d5s7 > means "controller 1 target 4 disk 5 slice 7". Doesn't have to be the > same syntax, of course, but we'd like to be able to reliably address a > disk, connected to specific hardware address (a port of a SATA card). I had always assumed that the symlinks in /dev/disk/by-path/ worked like that. Today I actually tried this; however, my system is much simpler than what you describe: I have two onboard SATA IDE Controllers (Intel ICH8) with 2 ports each, two hard disks and one CDRW/DVD drive. I found the behavior that I had expected: For example, when I switched my second HD from the first to the second port of the second controller and rebooted, the corresponding symlink in /dev/disk/by-path/ changed from pci-0000:00:1f.5-scsi-0:0:0:0 to pci-0000:00:1f.5-scsi-1:0:0:0. (00:1f.5 is the PCI address of this controller.) The symlinks of the individual partitions on that HD changed likewise. If I understand your previous emails correctly then /dev/disk/by-path/ does not work like that for you. That sounds like a bug of udev and/or the kernel (driver of the controller, hotplug subsystem or sysfs) to me. This makes it seem unlikely that you can use other information provided by udev (or HAL or sysfs) to reliably figure out which disk is connected to which port. Maybe you can check kernel.org if any substantial bugfixes were merged into the driver(s) of your controller(s) lately. The only workaround I can think of would be to write your own script to keep track of the disks, for example by maintaining a UUID vs. symlink lookup table. Udev can call this script whenever a disk is added or removed, and if you only swap one disk at a time then the script can reliably figure out which symlink has to be (re-)assigned to the new drive. Udev can then use the output of the script to (re-)create the correct /dev/mydiskXX (or whatever) symlink. The lookup table has to be saved such that it survives reboots, of course. That would ensure consistent access to the disks via the /dev/mydiskXX symlinks, but it seems like a bit too much of a hassle for a feature that should be provided automatically. -- Regards, | http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
