Subject: Re: Moving getmaxpartitions to libc
To: Wolfgang Solfrank <firstname.lastname@example.org>
From: Leo Weppelman <email@example.com>
Date: 09/02/1999 23:26:34
On Thu 02 Sep 1999, Wolfgang Solfrank wrote:
> > 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
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
[ 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
> 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 ;-)