der Mouse  <mouse@Rodents.Montreal.QC.CA> writes:
> Just to make sure we're talking about the same thing, you are referring
> to making DIOCSDINFO set the in-core label sticky, DIOCWDINFO set it
> non-sticky, and then have sticky (but only sticky) in-core labels
            ^ and write it to disk, of course.  8-)

> persist across all-partitions-closed, right?  And not even sticky
> labels persist across media change, for removable drives?

pretty much, yes.


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


> 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) - and unless there are spare bits lying around
> already, adding a sticky bit will grow the structure just as much as
> adding a checksum.  (I put "waste" in quotes both times because, as
> seems obvious from the conversation, not everyone agrees on which ones
> are actually "waste", as opposed to "worthwhile investment".)

If you're going to compare waste, then you also need to factor in all
of the code to calculate the sector checksum, including finding all of
the right blocks to checksum.  That's not going to be tiny, and
i think it's safe to say that an ioctl to clear a flag will be
smaller.

Off the cuff, i'd say that what you're advocating has more waste,
_and_ it's a worse design.  It's harder to maintain (how many
different checksums/sector finders do you need?), 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?), more prone to error
(checksums can be fooled accidentally... odds are low, but that's not
an error case that should be designed in), not as straightforward to
describe the semantics of to users, 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).  Sounds like a serious lose to me.


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