Hi,

> It looks like you are trading the problem of in-core disklabels that get
> lost on the last close with the problem of how to get rid of an in-core
> disklabel. Turning things around here does not solve the problems.

Well, IMHO there is not really a valid reason to want to get rid of the
in-core disklabel (except for media change of course (or hotswapping drives
etc.))

As far as I can see it, any program trying to change the on-disk label
should better be prepared to set the in-core label, too.  And no, I don't
see a dd of the label sector as a valid form of changing the disklabel
(especially, as on most(?) ports this wouldn't work anyway, as the
label sector is normally write protected).

One vaguely valid reason I can see for wanting to get rid of the in-core
label would be to check what default label the kernel will construct if
there is no valid NetBSD disklabel on the media.  However, I'm not sure
whether I want to go through the extra hassle of supporting the concept
of a non-sticky label just for that.

I'd much rather see some userland utility to generate in-core labels in a
way similar to what the kernel does for all supported disklabel formats
(more or less like the mbrlabel utility does).  That way, one gets the
advantage of being able to access the disk on any port.

But then again, I may be talking complete nonsense anyway.  I never could
come up with an explanation of why disklabel goes out of its way to write
the label explicitly to the disk itself instead of using the DIOCWDINFO ioctl
and be done with it.  Maybe someone can explain this to me?

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800