Date: Tue, 26 Apr 2011 15:24:50 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Alexander Motin <mav@freebsd.org> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org>, "Bjoern A. Zeeb" <bz@freebsd.org>, Robert Watson <rwatson@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Kostik Belousov <kostikbel@gmail.com> Subject: Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA] Message-ID: <BANLkTikkAQo=4=44GcLVvWm4Q7Wmt4BK8g@mail.gmail.com> In-Reply-To: <4DB58753.6020605@FreeBSD.org> References: <4DB54BA9.5050901@FreeBSD.org> <4DB55E86.7000805@yandex.ru> <4DB5685A.8010803@FreeBSD.org> <20110425141102.GJ48734@deviant.kiev.zoral.com.ua> <4DB58753.6020605@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 2011/4/25 Alexander Motin <mav@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: >>>>> =A0- old device names won't be seen inside GEOM, so users who hardcod= ed >>>>> provider names in gmirror/gstripe/... metadata (not the default >>>>> behavior) are still in trouble. >>>>> =A0- patch mimics ATA_STATIC_ID behavior, if user had custom kernel >>>>> without it, he should update device names manually. >>>>> =A0- it won't work for users with hot-unplugging ATA controllers (not >>>>> devices), but I believe it is really rare case. >>>>> =A0- low-level tools, such as smartmontools, won't be able to work wi= th >>>>> 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-s= tyle >>>> 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikkAQo=4=44GcLVvWm4Q7Wmt4BK8g>