Manuel Bouyer <bouyer@antioche.lip6.fr> writes:
> > If you do this, you can e.g. never sanely clear the disklabel on-disk
> > and have the kernel re-provide you with a default.
> 
> Unless we provide some way (ioctl) to invalidate the in-core disklabel.

This is broken.

Programs which desire a special, "sticky" label already have to be run
and coded specially in order to have any effect.  Force their code to
call the "set label stickly if no media change" ioctl, rather than the
general purpose set-label-and-write ioctl.

Maybe they're already doing that, as charles suggests (by using
DIOCSDINFO), and the DIOCSDINFO behaviour should remain unchanged from
how it is now.  (However, if this is true, some existing uses of
DIOCSDINFO are somewhat bogus.)  I'm not arguing that the notion of
having a 'sticky label' is bogus, i'm saying that have that be the
default when a label is read off the disk is bogus!

However, from the description of the behaviour seen, it seems that
label persistence occurs much more often than when DIOCSDINFO is
called.


In other words:

	* on first parition open:

		label_invalid = !have_a_label || media_change;
		if (!sticky || label_invalid) {
			read_label();
			sticky = 0;
			have_no_label_yet = 0;
		} else
			/* leave label alone */;

	* on DIOCSDINFO:

		assert(have_a_label);	/* at worst, if open, we have fake */
		set_in_core_label();
		sticky = 1;

	* on DIOCWDINFO:
		assert(have_a_label);	/* at worst, if open, we have fake */
		set_in_core_label();
		set_on_disk_label();
		sticky = 0;

	* provide a new ioctl to either clear 'sticky' or clear sticky
	  + reread from disk immediately.  (disklabel would probably
	  want to use this instead of DIOCSDINFO for the -r case.)

Note that I'd say that on a media change, even 'sticky' labels should
be cleared.


From the bug as described (which i've not looked into myself), just
reading the label on first device open causes 'stickyness.'  I don't
see how you can possibly describe that as a feature.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.