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

Stefan Bethke stb at lassitu.de
Wed Oct 13 09:47:44 UTC 2010


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.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811



More information about the freebsd-stable mailing list