Re: Unpredictable drive naming with multiple SATA controllers
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 |
Reply to: