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 <s...@lassitu.de> Fon +49 151 14070811 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
