From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:58:08 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 D3FB2106564A for ; Mon, 25 Apr 2011 14:58:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C45B8FC0C for ; Mon, 25 Apr 2011 14:58:07 +0000 (UTC) Received: by bwz12 with SMTP id 12so2604656bwz.13 for ; Mon, 25 Apr 2011 07:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=esBXlUI0SwMthP1xL2JI1PlG73f4SA1vgaFUpFKdK3A=; b=SCPl+UxLVsaEgb/d0FQziJjXyqaS5mcQzJlGn3yLRHxm1lX42LZUL9xpWIivRNVL54 ybCNMseIz75yw5FNpmx0d8Uqauz7oiwP44CP20sALuP8RZpEPIYWmSrN1yBFIckiNUiX QqYUS5lyVIn+K7IEqdnUY6F3SnrefVGbCcoYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Xlwy/E2GBhCZWhzv8XvTmxxSUSArT5fcWOoku+V5XR9uHR6Vwp3ikVf4mZndOy9gJ7 K9JNUSwZPl221Wr6XyqvU3Jh0tpK+0ceXKhEaCWbLzLlMgqw3hG7ui85E2zOlKFsT6mk +sFQP2CcW2yu7bRXfEVESABh3fwKGhJw9yvhs= Received: by 10.204.83.212 with SMTP id g20mr3344529bkl.55.1303743487122; Mon, 25 Apr 2011 07:58:07 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id x6sm3310640bkv.12.2011.04.25.07.58.05 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 07:58:06 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB58BF9.9070901@FreeBSD.org> Date: Mon, 25 Apr 2011 17:58:01 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Kostik Belousov References: <4DB54BA9.5050901@FreeBSD.org> <4DB55E86.7000805@yandex.ru> <4DB5685A.8010803@FreeBSD.org> <20110425141102.GJ48734@deviant.kiev.zoral.com.ua> <4DB58753.6020605@FreeBSD.org> <20110425144828.GK48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110425144828.GK48734@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current 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: Mon, 25 Apr 2011 14:58:08 -0000 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