From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:38:19 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 258F2106566B; Mon, 25 Apr 2011 14:38:19 +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 1EA2D8FC14; Mon, 25 Apr 2011 14:38:17 +0000 (UTC) Received: by bwz12 with SMTP id 12so2582439bwz.13 for ; Mon, 25 Apr 2011 07:38:17 -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=eUxFmbCSXIKqEPUC63vL6zj5V/wxUVVjVr8nYAtLWJo=; b=i1hkKM5Qn3tqiCcnYy1hq15vKA1UdViqFqWtsaq56P6wkA72UIW33ur5HqmoMzVAYQ V00hIHz87/wasYQQXTSvkOUflCWs/zP7YLIycugv6L1UCZCXDi+VX5mUJ9Ev17LUITru 4VJFT8VrGSe9BBoTjf2uI0vNIHRwbwtHC+C5Q= 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=devHCYQkLqbkTCJX2tddddz+z6R083GdnXdYx+6nMAbV7/JScfAQ3s5PPzCyZqJqr0 Fn3J7Y4NABNi76fpBVKEG983AiiS89La5t0dJg/nwqPkbun/lezZU8gu112Kn1kyXrwI xBN5HmrbNYPhXRhn3su+bhKxnifvMeYBg9Mfk= Received: by 10.204.170.193 with SMTP id e1mr3175948bkz.136.1303742296929; Mon, 25 Apr 2011 07:38:16 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm3304735bkm.6.2011.04.25.07.38.15 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 07:38:16 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB58753.6020605@FreeBSD.org> Date: Mon, 25 Apr 2011 17:38:11 +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> In-Reply-To: <20110425141102.GJ48734@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , "Bjoern A. Zeeb" , "Andrey V. Elsukov" , Robert Watson , 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:38:19 -0000 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. > 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