Date: Wed, 13 Oct 2010 11:47:41 +0200 From: Stefan Bethke <stb@lassitu.de> To: Pawel Jakub Dawidek <pjd@freebsd.org> 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: <BE3B2824-F4D0-4B06-9323-51DF1438C632@lassitu.de> In-Reply-To: <20101013082036.GK2197@garage.freebsd.pl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) >>=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/. 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. Stefan --=20 Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE3B2824-F4D0-4B06-9323-51DF1438C632>