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

Hi,

2011/4/25 Alexander Motin <mav_at_freebsd.org>:
> Kostik Belousov wrote:
>> On Mon, Apr 25, 2011 at 03:26:02PM +0300, Alexander Motin wrote:
>>> Andrey V. Elsukov wrote:
>>>> On 25.04.2011 14:23, Alexander Motin wrote:
>>>>> 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?
>>>> what about new GEOM class? You can create new class instance after
>>>> disk_alloc(), attach it to the new disk and create provider with old-style
>>>> name. It seems this class will be very simple.
>>> It sounds like less dirty option. I'll try it. Thank you. Won't
>>> re-providing exactly the same device into GEOM create some problems?
>>> glabel and co will connect to each of them (original and legacy) and
>>> report two equal sets of labels.
>
> I have implemented it by adding one more specialized glabel submodule:
> http://people.freebsd.org/~mav/legacy_aliases_geom.patch
>
so far, so good, with that patches on 2 different machine with
different ATA mapping (one was detected as ad0, the other ad6). I only
tested the first patch on a single machine (was ad0), worked too.

Thanks,
 - Arnaud

> But when I already done it, I understood where will be the problem: if
> somebody open any partition on the device with the new name, all legacy
> names will become inaccessible (busy), and vice versa. It could be not a
> big problem if it would only be user's choice -- we could say just: "use
> one or another, not both". But provider could be chosen blindly by some
> GEOM class, such as glabel, and then it turns into pure lottery.
>
> So while from the code side and for point of supporting hardcoded
> provider names it looks much better, it probably won't work so.
>
>> Can you limit the real functionality of this new class to the calls
>> to make_dev_alias(9) ? Ideally, I would think about some extension of
>> the core GEOM, which would take some parameter, lets call it alias
>> name, and will acompany the existing make_dev() calls with parallel
>> make_dev_alias().
>
> Adding one more alias name field to the struct g_geom probably is not a
> problem. And the result probably would not have downsides of two
> previous approaches. And from the code side it would probably looked
> better then textual parsing in a first patch. But supporting alias in
> every place where names used in GEOM (that is required to make it
> usable) will probably require quite a massive set of changes though GEOM
> core and many classes. I am not sure I want to go there.
>
> --
> Alexander Motin
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>