From owner-freebsd-stable@FreeBSD.ORG Wed Oct 13 13:31:25 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E4610657F3; Wed, 13 Oct 2010 13:31:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5CE18FC08; Wed, 13 Oct 2010 13:31:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3F5F546BA7; Wed, 13 Oct 2010 09:31:24 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD9548A027; Wed, 13 Oct 2010 09:31:19 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 13 Oct 2010 09:29:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101012185100.5AA661CC3E@ptavv.es.net> <20101013112630.GA1727@garage.freebsd.pl> In-Reply-To: <20101013112630.GA1727@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010130929.18350.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 13 Oct 2010 09:31:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: stable@freebsd.org, "Andrey V. Elsukov" , Pawel Jakub Dawidek , Stefan Bethke , Jeremy Chadwick Subject: Re: Label question...why does ufs label vanish on mount? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:31:25 -0000 On Wednesday, October 13, 2010 7:26:30 am Pawel Jakub Dawidek wrote: > On Wed, Oct 13, 2010 at 11:47:41AM +0200, Stefan Bethke wrote: > > Am 13.10.2010 um 10:20 schrieb Pawel Jakub Dawidek: > > > > > On Tue, Oct 12, 2010 at 11:33:11PM -0700, Jeremy Chadwick wrote: > > >> On Wed, Oct 13, 2010 at 08:29:06AM +0200, Stefan Bethke wrote: > > >>> That explains the mechanism, but not the rationale. Or is it just an unintended consequence? And how is da2p1 different from ufs/mylabel? (Mount da2p1 and ufs/mylabel is removed, but not the other way around.) > > >> > > >> Pulling in pjd@ who can probably shed some light on this. > > > > > > The ufs/mylabel provider is based on da2p1, that's why opening da2p1 > > > makes ufs/mylabel to be removed and not the other way around. > > > > > > The ufs/mylabel provider was created, because when da2p1 provider was > > > created and LABEL class tasted it, it discovered that this provider > > > contains UFS file system with 'mylabel' volume label, so the LABEL class > > > created ufs/mylabel provider. Now when you open da2p1 for writing, the > > > LABEL class destroys ufs/mylabel, because you may decide to change > > > metadata on da2p1, for example you may choose to destroy UFS in there or > > > change the volume label. When write open count on da2p1 goes down to > > > zero, the LABEL class will be given da2p1 provider for tasting once > > > again, so it can rediscover (possibly modified) volume label. > > > > > > The class may choose to ignore the spoil event from GEOM (it is send on > > > first open for write), but if it isn't based on autodiscovering > > > metadata. For example the NOP class ignores this event, because it > > > doesn't care about metadata of provider it is based on. > > > > > > If we choose to ignore the spoil event in the LABEL class we will end up > > > with stale info, eg. open da2p1 for writing, change its volume label and > > > mount it and you will still have old label in /dev/ufs/. > > > > Thanks a lot (and also to Andrey), that really makes it clear to me! > > > > I just wish there was an easy way to keep the labels around even while someone has the provider open for writing, but I now understand that this requires some significant changes. > > The changes aren't significant. We could eventually ignore spoil event > and keep labels around even when underlying provider is opened for > writing risking the label is stale. We could then only update or remove > the label on retaste event (when underlying provider's open write count > goes down to zero). We really should fix this. The current behavior is highly non-intuitive and confusing. For example, if you label a filesystem because you want to switch over to labels, you can't verify that the labels exist in /dev/ufs when you go to edit your fstab (if the filesystems are mounted via existing non-label mounts). > Currently when we do, eg. > > # dd if=/dev/zero of=/dev/da2p1 bs=1m > > This is happening: > > # dd(1) opens da2p1 for writing > # GEOM sends spoil event to all consumers of da2p1 > # LABEL class destroys /dev/ufs/mylabel provider > # dd(1) finishes and closes da2p1 > # GEOM sends taste event to all GEOM classes > # LABEL class finds no metadata and ignores da2p1 > > With the new world order this would look like this: > > # dd(1) opens da2p1 for writing > # GEOM sends spoil event to all consumers of da2p1 > # LABEL class ignores spoil event > # dd(1) finishes and closes da2p1 > # GEOM sends taste event to all GEOM classes > # LABEL class finds no metadata on da2p1 and destroys /dev/ufs/mylabel What happens if you change the label of a filesystem? I suppose in the UFS case we don't let you use tunefs to change the label of a mounted filesystem? Do we have any filesystems where that is the case? If not, I think this approach sounds fine. -- John Baldwin