der Mouse  <mouse@Rodents.Montreal.QC.CA> writes:
> > and the faked-up label generated by the kernel when it saw no
> > disklabel is more correct?  How do you get back to that label?
> > "unglue the label."  8-)
> 
> Hmm.  The only way I can see involves modifying the label sector
> (though it can then be modified back right away).  While this is
> kludgy, I can't see even a kludgy way to unstick a sticky label under
> your scheme without the ioctl.

The entire point of such an ioctl is to keep it from being a kludge!


> If the kernel already has a reasonably strong checksum algorithm in it
> already (doesn't the rnd pseudo-evice use md5?), this overhead is
> essentially zero.

And if you don't enable rnd?  "then it's overhead."


> Even if not, it's still pretty small (I could
> probably write a CRC routine in no more than half a dozen lines, though
> it would run faster if you let me add a 256-entry table).

You brought up the overhead of my proposal.  My point here is that the
thing that you're advocating has at least as much.


> > including finding all of the right blocks to checksum.
> 
> This is a non-starter of an argument, since code to find them is needed
> to load disklabels off packs anyway.

Uh, sure, the code to find them is needed...

but now you have to find them two different ways (once to use, once to
checksum... or maybe you could combine them somehow, but you still
need a separate entry point t get the checksum unless you want to
change all of the existing entries), then you need to add the right
calls to the checksum function, and there's probably more than that...

_and_ to implement a clean way of unsticking the label you _still_
need to implement an unstick ioctl.  (hell, what if the disk is
write-protected and therefore unwritable, so you couldn't even
intentionally frob some blocks -- if you could find the right ones to
frob?  Then you're SOL?  I think any "design" that gets you into this
pit is, uh, very bad design.)


> > It's harder to maintain (how many different checksums/sector finders
> > do you need?),
> 
> One checksum routine which is probably already there; sector finders
> are already present in the MD disklabel readers anyway.

In fact, though, this is simply wrong:

* the checksum may not be there already.  you're making it mandatory.

* you're adding overhead of at least an extra entry into the MD
disklabel code, as well a bunch of other code changes unless you want
to duplicate the block-finding code that's there now (which would,
of course, add overhead).

Further, you then need to start wondering about the implications of
what you're summing for different 'partition schemes.'  some partition
schemes' partition table locations are other partition schemes' file
system data blocks.  There are just too many failure cases.


> > less well-defined (what exactly causes a sticky label to be reset?
> > which sector do i have to change on my disk, and change how?),
> 
> Under Bill's scheme as I see it, the label is updated from the pack
> exactly when a "first open" is done and either there is no in-core
> label or the label sector has changed since that in-core label was set.
> (It might, but arguably might not, be a good idea to add "or the drive
> says the media has been changed".)  There is no such explicit notion as
> a sticky label; this simply corresponds to a label that was set in-core
> but not on-disk, and the label sector hasn't been changed since.

what is the label sector?  how do i know what sector to right to cause
a refresh?  what if the port supports multiple partition schemes?
what if the disk cannot be written for some reason?  (why should i
have to write my disk when i don't want any bits written to the disk,
and that's why i set an in-core label to begin with?!)

I don't think there's any good, easily explained, general answer to
_any_ of these questions with this scheme.


> > more prone to error (checksums can be fooled accidentally... odds are
> > low, but that's not an error case that should be designed in),
> 
> True, which is why I said what I did about keeping the whole label
> sector around.  (Which would impose a run-time cost but no code
> complexity cost.)

sector?  no, sectors.  you've gotta keep around -- or checksum -- the
sectors that are relevant to the disklabel calculation.  on some
ports, that might mean:

	BSD disklabel sector
	DOS MBR sector
	other scheme-specific sectors.

It's not just one.


> > not as straightforward to describe the semantics of to users,
> 
> Perhaps.  Except for defining the terms (like "first open"), I think I
> described above the semantics of the scheme I'm advocating.  One
> sentence; three lines.  My summary of the scheme you advocate looks
> comparable to me, based on what I wrote in the message you replied to.
> Which one would be clearer to users is a good question, one I don't
> feel competent to more than guess at.

I don't think you can provide a general, consistent answer to any of
the questions i asked above.  they procedure to do things like those
is trivially explained in the scheme i proposed.


> > and, finally, needs significant interface work before it can even be
> > considered a viable solution (e.g. a way to figure out which sectors
> > are to be checksummed has to be defined).
> 
> Exactly those sectors that would be used to update the in-core
> disklabel based on the on-disk disklabel - knowledge which has to be
> present anyway to do read-from-pack disklabels at all.

Yes, but information which is not easily extracted with either:

	* significant code modification, or

	* overhead due to duplication of code (whch renders your point
	  of being lower-overhead -- already shot in the head -- even
	  more dead).

In other words, if you want your claims to be even close to be true,
you _have_ to redesign interfaces.



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