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

[John Baldwin]

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