>> In that case, I see a price to it: it seems to me - and to you too,
>> based on the message I saw - that it calls for at least one new
>> ioctl, to de-sticky a sticky in-core label.

> I think you have to have that anyway.

> What if you decide that the sticky label you set on your
> non-removable disk is 'wrong'

I assume you mean "label set with DIOCSINFO", or something like that.
Sticky labels don't really exist in any other sense under Bill's
proposal (as I understand it, at least).

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

Admittedly this is a bit of a hairsplit.  You raise a good point; this
need had not occurred to me.

>> Personally, I prefer to "waste" memory on storing the label sector
>> than to "waste" the resources that would be consumed by your
>> approach (mostly the extra ioctl)
> If you're going to compare waste, then you also need to factor in all
> of the code to calculate the sector checksum,

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

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

> Off the cuff, i'd say that what you're advocating has more waste,
> _and_ it's a worse design.

More waste...who knows.  Only way to tell for sure is to implement
both, and that would require someone who cares more than me.  If
someone implements your scheme, I'll probably grumble vaguely to myself
and use it, since while I prefer Bill's, yours is "good enough" for me.

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

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

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

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

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

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B