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

Wed Oct 13 08:46:56 UTC 2010

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:
> > Am 13.10.2010 um 06:56 schrieb Andrey V. Elsukov:
> > 
> > > On 12.10.2010 22:51, Kevin Oberman wrote:
> > >> For some reason the /dev/ufs/label entry that geom creates for every UFS
> > >> formatted partition is deleted when the device is mounted. This is not
> > >> the case for other file systems, though I have not tried them all. It
> > >> makes the drive much harder to deal with when you have to keep track of
> > >> which physical drive contains the labeled media. It is a particular
> > >> issue for hald and the tools which depend on it.
> > >> 
> > >> Is there a good reason for this odd behavior of UFS? If there is not a
> > >> good reason, could it be changed?
> > > 
> > > When you are opening provider for writing (i.e. mount FS) GEOM(4)
> > > initiates SPOILING and all consumers that are attached to this provider
> > > 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.
> > 
> > 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/.

-- 
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/779651e8/attachment.pgp