From owner-svn-src-head@freebsd.org Mon Jul 18 19:37:42 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21F20B9D04C for ; Mon, 18 Jul 2016 19:37:42 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCA041946 for ; Mon, 18 Jul 2016 19:37:41 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x234.google.com with SMTP id f6so75855525ith.1 for ; Mon, 18 Jul 2016 12:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Gt2MRXUzSh3TrtgviKtD+ogKOXWEELccKlxlVu25fT4=; b=rm0/zGd97tBYJXzYDbqFQkCnUDTZQUWgO1eJCaBOrwilaRmC/RFe4ve9TZKU6kAHu+ ktGTiKxrBaTXCjU3vsiUrGrE5S7teaWQc0VTHJfR/WVPgiy1EFIG824lpFyzuuWK1o7b iDM1XZb8JPFGMSBF6I5BO4cCVFUKnASZt21CKTbHhOkgnM1V5iRd2vKjHbUljggUbGWp x/36NzSSJm9rSBxwTr6+853sIFVChLEUsOyulwR5m5eFq7onXt+CpoG0U0KLOHtt0vK/ q5NACr/SgxcyENgGVqXr7y2ICKgOkPuq4mkTo6IrS7DW8HmEbf1IrdFEFNrMY+w3tae+ 15qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Gt2MRXUzSh3TrtgviKtD+ogKOXWEELccKlxlVu25fT4=; b=WKjfljrh7mZ83xFZJvZosIq7DU/PnEo4KYHVPqKk4Mdlaq/6cteMv1A/+iVSnSO1Bf DtPtHuPWFnRDB/SEOfixDmiv/+cgSuigMcObjhaCKeirC6WjSqeCkOi2gWcGlRUyujb4 kKGCorbQKB1Smbdr1CEIgEArMKhyZ0W7+nNHL34xCVkOtGpTXFiMbXblp+A4Re97Je3Q LUw4GlBbBePF9VjgbfZbOyheWXti0Yzt0Th1W50Yja+1ArkZO5NuSPwJdXERZA1rO1Hc rtoLiJh5sI5UcUG34TpvGfK7fMx1PukZzSYr/wNvw0IrmqClE1AEMWwaNA7E94TnbN8F 9cBw== X-Gm-Message-State: ALyK8tKFqXLulQZT8JZrw/E+aJRaX1+PM/NNMvLAh4EMY682n2MX/HUk6OuHitwb4kfy5F2C5F5P8Y2wovwR/89k X-Received: by 10.36.118.19 with SMTP id z19mr122919itb.44.1468870661149; Mon, 18 Jul 2016 12:37:41 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.59.193 with HTTP; Mon, 18 Jul 2016 12:37:40 -0700 (PDT) In-Reply-To: <61cba001-2717-49ee-843e-5ed6d18fa17b@yandex.ru> References: <201607180500.u6I501CX063743@repo.freebsd.org> <20ae3dfe-96f4-c897-67d0-71bb94d14858@yandex.ru> <61cba001-2717-49ee-843e-5ed6d18fa17b@yandex.ru> From: Maxim Sobolev Date: Mon, 18 Jul 2016 12:37:40 -0700 X-Google-Sender-Auth: klxnuK1TIf9wcAiLv9zxjE-qS1g Message-ID: Subject: Re: svn commit: r302985 - head/sys/geom/label To: "Andrey V. Elsukov" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 19:37:42 -0000 Well, this looks to me exactly what I am talking about. With this change we are only allowing underlying provider to be *slighly* bigger than the UFS size. So as I said it's pretty harmless to do so, or at least I think it is. In general I think this case is underlying some missing design feature of GEOM framework, which basically gives provider to a first bidder that likes the taste of it. What needs to be happening instead is to have some rank in there, so if consumer A and consumer B both "like" the taste, but provider A has bigger rank it would be given a preference. Then "whole disk" partitioning schemes (mbr, gpt) could be given biggest rank, BSD label and friends slightly smaller, encryption/compression yet smaller and providers that just "decorate" things, like LABEL the lowest possible. -Max On Mon, Jul 18, 2016 at 12:13 PM, Andrey V. Elsukov wrote: > On 18.07.16 17:24, Maxim Sobolev wrote: > > Andrey, are you talking about this: > > > > --- > > r156299 | pjd | 2006-03-04 11:41:54 -0800 (=D1=81=D0=B1, 04 =D0=BC=D0= =B0=D1=80 2006) | 11 lines > > > > We need to check if file system size is equal to provider's size, becau= se > > sysinstall(8) still bogusly puts first partition at offset 0 instead of > 16, > > so glabel/ufs will find file system on slice instead of partition. > > > > Before sysinstall is fixed, we must keep this code, which means that we > > wont't be able to detect UFS file systems created with 'newfs -s ...'. > > > > PS. bsdlabel(8) creates partitions properly. > > > > MFC after: 3 days > > --- > > > > In which case this particular change has a better chance of working > > since it's not removing this check but making it less strict. Therefore > > it might attach to a wrong provider only if first UFS slice is the only > > one slice on partition (or if the other partition is very small - less > > than 256 blocks in size). In either of those cases I don't think it > > makes much difference if we are attaching to a slice or a partition. > > No, I mean r235918, that was reverted after several complains. > UFS label is a special label. It always had the same size that provider. > Now it will attach to first provider that will be tasted. It can be > gmirror, generic glabel, geli, gpart, mbr, whole disk. > > https://lists.freebsd.org/pipermail/freebsd-geom/2009-April/003473.html > > -- > WBR, Andrey V. Elsukov > >