Label question...why does ufs label vanish on mount?

[Pawel Jakub Dawidek]

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).

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

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20101013/421131eb/attachment.pgp