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

Kostik Belousov wrote:
> [Cc: list trimmed]
> 
> On Mon, Apr 25, 2011 at 05:38:11PM +0300, Alexander Motin wrote:
>> 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
>>
>> 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.
> If ad4 is an alias for ada0, carry UFS on s1a, for instance, and both
> ad4s1a and ada0s1a are mounted rw, user will get (probably unrepairable)
> fs corruption. Not sure about double-import of ZFS pools.

This is not a problem, GEOM will not allow double open in that case and
that is actually where problem I mentioned grows. I was talking about
the other case: if ada0s1a opened by glabel during root mounting using
UFS ID, swapon for swap mentioned in fstab as /dev/ad4s1b will fail.

>>> 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