From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 19:24:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F224D106564A; Tue, 26 Apr 2011 19:24:51 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7E66A8FC18; Tue, 26 Apr 2011 19:24:51 +0000 (UTC) Received: by iyj12 with SMTP id 12so1087430iyj.13 for ; Tue, 26 Apr 2011 12:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bmLPdH/UW2KapWtrNOsj25UGo2w93fc8nS+TQLzJNaM=; b=Z89fRo5q44AoWxniUElwhKS2RxNxtt6y0ZnSXB8Z+dw2Viflvq1N89vGXltf3o5jdn Mru07u2T6ocR92+qtDdBHQbOmAwQED1p/x9UPMJEcx6m7P/iC5ae1Pq3COoCQCSADbOr SmRYd3AgMyjvhi9pz3pEcsJi555W+tWq10i+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JtPiYgRlmAVu+foPxml8pOzyDoAHIv8O48Lkgi88Z31YOGY9wqmUVyDhW05/9VdYfI 2KEXB35eWJcKABiqwMtWnvBvS9uR5Dmvbeqf10kHPwQvjupHYdH84ByrVIn9RwltnIwm scXS9mWHh9AfHlZv7cXM03BcOU2YnLAnWC7Mk= MIME-Version: 1.0 Received: by 10.43.44.6 with SMTP id ue6mr1444846icb.69.1303845890730; Tue, 26 Apr 2011 12:24:50 -0700 (PDT) Received: by 10.42.177.134 with HTTP; Tue, 26 Apr 2011 12:24:50 -0700 (PDT) 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> Date: Tue, 26 Apr 2011 15:24:50 -0400 Message-ID: From: Arnaud Lacombe To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pawel Jakub Dawidek , FreeBSD-Current , "Bjoern A. Zeeb" , Robert Watson , "Andrey V. Elsukov" , Kostik Belousov Subject: Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 19:24:52 -0000 Hi, 2011/4/25 Alexander Motin : > 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= " >