On Thu 02 Sep 1999, Wolfgang Solfrank wrote:
> 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.))

And when you are meddling with the disklabel - as you mention below.

> 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).

I think we do (mostly) agree here. A dd(1) is a very rough kind of labeling
a disk ;-) There are a few points worth mentioning though:
   1)  Since historically, the in-core disklabel was dropped on the last
       close, there are programs and procedures that depend on it.
       [ I think this being the right version of history was 'proven' in
         the thread on thech-kern. Correct me if I'm wrong ]
   2)  Because of 1), most ports could do without an 'mbrlabel-like' program,
       since the kernel would reconstruct the in-core label for them.
       You can argue that it would be nice and handy to have an mbrlabel-like
       program for each native label type - as you actually do below. And
       all I can say is: yes, but not forced by an API change that
       'just-went-in'. So in this case, I want a way to drop the in-core
       label.
       [ What I mean is, on the atari port, there is a tool to modify
         partition id's. By changing id's, you indirectly change the way
         the kernel constructs the in-core label. ].
   3)  On some ports, the native label is scattered over the disk. On the
       atari, there can be a chain of mbr-like sectors (I _think_ this is
       possible on the x86 too, but I'm not sure). You cannot protect all of
       them. So what's the protection worth in practice?
       [ Just a thought: Maybe the protection flag (DIOCWLABEL) can be used
         to select behaviour? I.e. why drop a protected label? ]

> 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

Or the kernel is the only one that _can_ currently construct an in-core
label.

> whether I want to go through the extra hassle of supporting the concept
> of a non-sticky label just for that.

I would turn this around: the non-sticky label _was_ supported. The sticky
one is now half supported (I guess only for disks through the scsipi-layer).

> 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.

I would like this too. At least I already made someone happy with the
mbrlabel program. He can now read iomega formatted zip disks on the atari;
these have an mbr-label ;-)
The disklabel stuff needs updating. That's why I started this thread in
the first place. I hope to wring out some proposal out of the threads on
this subject ;-)

Leo.