Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]

From: Marius Strobl <marius_at_alchemy.franken.de>
Date: Mon, 25 Apr 2011 14:16:25 +0200
On Mon, Apr 25, 2011 at 01:23:37PM +0300, Alexander Motin wrote:
> Hi.
> 
> I've implemented following patch to keep basic compatibility for the
> migrating users. I don't like such hacky things, but at least I tried to
> make it less invasive.
> 
> The idea:
>  - New xpt_path_legacy_ata_id() function in CAM tries to predict bus
> unit number and then device unit number for specified path, as if it was
> with legacy ATA with ATA_STATIC_ID option.
>  - on attach, ada driver fetches that number (if not disabled using
> tunable kern.cam.ada.legacy_aliases), prints to console something like:
> ada0: Previously was known as ad12
> , and sets kernel environment variable like:
> kern.devalias.ada0="ad12"
>  - when geom_dev tastes new geom and creates device node for it, it also
> tries to match prefix of the device name with present kern.devalias.*
> enviromnent variables, and, if some match found, creates alias with
> substituted name (ada0 -> ad12, ada0s1 -> ad12s1, etc.).
> 
> The patch is here: http://people.freebsd.org/~mav/legacy_aliases.patch
> 
> I did few tests and it seems like working -- two sets of device nodes
> appeared for each device, I can successfully label and mount any of them.
> 
> What will not work:
>  - old device names won't be seen inside GEOM, so users who hardcoded
> provider names in gmirror/gstripe/... metadata (not the default
> behavior) are still in trouble.
>  - patch mimics ATA_STATIC_ID behavior, if user had custom kernel
> without it, he should update device names manually.
>  - it won't work for users with hot-unplugging ATA controllers (not
> devices), but I believe it is really rare case.
>  - low-level tools, such as smartmontools, won't be able to work with
> alias devices, as background ada driver doesn't implements legacy
> ioctls. May be I could partially fix this.
> 
> Except those, I think this patch should work for the most of users.
> 
> Any more objections/ideas? Is this an acceptable solution?
> 

Hi,

given that only the amd64, i386 and pc98 GENERIC kernel configuration
files had ATA_STATIC_ID enabled by default it would be highly desireable
that your compatibility shim also only mimics that behavior on these
archs or probably better actually check for ATA_STATIC_ID and put that
option back into the respective kernel configuration files.

Marius
Received on Mon Apr 25 2011 - 10:16:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC