Date: Wed, 13 Oct 2010 13:26:30 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Stefan Bethke <stb@lassitu.de> Cc: stable@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: Label question...why does ufs label vanish on mount? Message-ID: <20101013112630.GA1727@garage.freebsd.pl> In-Reply-To: <BE3B2824-F4D0-4B06-9323-51DF1438C632@lassitu.de> References: <20101012185100.5AA661CC3E@ptavv.es.net> <4CB53BF7.1020408@yandex.ru> <B6AAC89E-5651-4B4B-B770-11443A7BCC22@lassitu.de> <20101013063311.GA51239@icarus.home.lan> <20101013082036.GK2197@garage.freebsd.pl> <BE3B2824-F4D0-4B06-9323-51DF1438C632@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 13, 2010 at 11:47:41AM +0200, Stefan Bethke wrote: > Am 13.10.2010 um 10:20 schrieb Pawel Jakub Dawidek: >=20 > > 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? (Mo= unt da2p1 and ufs/mylabel is removed, but not the other way around.) > >>=20 > >> Pulling in pjd@ who can probably shed some light on this. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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/. >=20 > Thanks a lot (and also to Andrey), that really makes it clear to me! >=20 > I just wish there was an easy way to keep the labels around even while so= meone has the provider open for writing, but I now understand that this req= uires 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). Currently when we do, eg. # dd if=3D/dev/zero of=3D/dev/da2p1 bs=3D1m 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 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAky1l2YACgkQForvXbEpPzRgngCg6EgutPHkg7i3WYUe+6IpUf3V kF8AoMriVzdeaTp1Llm6AmpXxPHiewy5 =qD8P -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101013112630.GA1727>