Why not just name the cam-ata devices the same as the old names?

Peter Jeremy peterjeremy at acm.org
Wed Apr 27 21:25:26 UTC 2011


On 2011-Apr-26 22:46:20 -0700, Freddie Cash <fjwcash at gmail.com> wrote:
>This is where labelling *disks* is the better route.  Filesystems come
>and go, but the disks don't change very often.  This is one the nicest
>things about using FreeBSD systems (all the GEOM stacking and
>labelling).

But disks _do_ get changed for various reasons (eg failure).  If we
move to a an identification approach that is based on the physical
disk, rather than some variant on the path to a disk, we need to
ensure that the disk replacement procedure is well documented.

One associated issue is determining what disk you are booting from -
my main system has 6 disks spread across 3 controllers.  Whilst the
BIOS reports size and model, it doesn't report serial number (and the
mapping of SATA port to legacy PATA channel/master-slave is
non-obvious and as tripped me up in the past).  By the time I get to
loader(8), I'm just presented with 'C' through 'H' (mapped to disk0
thru disk5).  There is no way to map this to either physical disk
(though this is probably the fault of my BIOS) or to FreeBSD device
names.  loader needs to grow enough smarts to be able to report a
disk serial number (where possible) and there nees to be a tool
that can map between loader and FreeBSD disk names (though it's
not clear whether this belongs in loader(8), the kernel, userland
or some combination).

As for the ad->ada renaming: I went through this some time ago (by
manually switching my kernel from ata to ahci), resulting in ad{4,6,8}
becoming ada{0,1,2}.  Whilst I was aware of the issue, I still managed
to confuse myself and I think it took me at least one reboot to get
the names straight.  (Thought ZFS took the renaming of the devices
underlying my data pool in its stride).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110427/82726728/attachment.pgp


More information about the freebsd-fs mailing list