From owner-freebsd-stable@FreeBSD.ORG Wed Oct 13 08:55:04 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 F1C78106566C for ; Wed, 13 Oct 2010 08:55:03 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id 68F0E8FC0A for ; Wed, 13 Oct 2010 08:55:03 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward5.mail.yandex.net (Yandex) with ESMTP id AC87114D0908; Wed, 13 Oct 2010 12:55:01 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1286960101; bh=K4YMyzudn1bC5o0U8Lc3/WKeIuv3CUu2/6Ihq1V/PcA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=C96aJIrXsLGxOzfooxcQARk3QcR9ypfmCgTKhno6d/CSd1SZxnRyXowjFSHCJ05O+ bHkel502uTtmXOiXR89Llu1Sc8kuLMGrm8EGDV0ET8z7UzIZjq0Bd33chURYFKBHkj U2KIC74vgQLv8ztpN5AHM/aFR0mcQmFVHhxoHohk= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 5BAEE290062; Wed, 13 Oct 2010 12:55:01 +0400 (MSD) Message-ID: <4CB573E0.1030104@yandex.ru> Date: Wed, 13 Oct 2010 12:54:56 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Stefan Bethke References: <20101012185100.5AA661CC3E@ptavv.es.net> <4CB53BF7.1020408@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F0E3C2540D8068FEB5F1F7D" X-Yandex-TimeMark: 1286960101 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Cc: stable@freebsd.org 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 08:55:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F0E3C2540D8068FEB5F1F7D Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 13.10.2010 10:29, Stefan Bethke wrote: >> When you are opening provider for writing (i.e. mount FS) GEOM(4) >> initiates SPOILING and all consumers that are attached to this provide= r >> except one will self-destroyed. When you are closing provider GEOM(4) >> initiates TASTING and consumers can return back. Look at man 4 geom >> for details. >=20 > That explains the mechanism, but not the rationale. Or is it just an=20 > unintended consequence? And how is da2p1 different from ufs/mylabel? > (Mount da2p1 and ufs/mylabel is removed, but not the other way around.)= This is by design. Any provider's entries in /dev are created by GEOM_DEV= class. GEOM_PART serves partition tables. GEOM_PART_GPT as part of GEOM_P= ART serves GPT. GEOM_PART creates new provider for each entry in GPT. For example: da2 has GPT. da2p1 - first entry in GPT. GEOM_PART creates da2p1 provider= and GEOM initiate tasting. GEOM_DEV creates new consumer for da2p1 and /dev/da2p1 entry in devfs. At the same time GEOM_LABEL checks this provid= er and if it found "labels" it creates new consumer and new provider with na= me ufs/mylabel via slicer interface. After creating new provider GEOM initia= te tasting again. And GEOM_DEV creates new consumer and /dev/ufs/mylabel ent= ry. So, now we have two providers through we can get access to one device. But ufs/mylabel's is on top of da2p1. When we do first open one of them f= or writing GEOM initiate spoiling for protecting from stale metadata. When w= e do open da2p1 then GEOM_LABEL receives spoil event and destroys own provi= der. If I'm wrong Pawel can correct me. --=20 WBR, Andrey V. Elsukov --------------enig0F0E3C2540D8068FEB5F1F7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJMtXPjAAoJEAHF6gQQyKF6CY0H/0N2S7hsxzIdyg8uSKDrWpQ+ laAFM8AOhVArtNv0/KfPQnNm670rEeNZYfZhwNnutblhvBnNR3J/ZctgwE5mrmx6 6xXwKKz5Md/FCeZolgFAy74LL+9CFiqws6tfTffUqXpuEY5o0OZb0cnxeaN1xLQS G/cLQ1V2oHufOm1Fd1dIQVzJ0iHkNbLXT1TgiWzPHTrkWj1w3Ke2azRhQFxxLb/9 6FUUtIbkRcJH/4Elk/TJ3aMUfQ1hmPIx6Ih0+Gfhs9gThK860f4nSneZxD4V9Whr 6l/0Q0ZBljru0MJ+/eSmPbATkeB6YLmBiDuDV79icUiNF8RXLb0XTaRcCypXzO4= =j7M0 -----END PGP SIGNATURE----- --------------enig0F0E3C2540D8068FEB5F1F7D--