> How about this for a compromise: on re-open, we check to see if the
> diskabel block has changed and only recompute the in-core disklabel
> if it's changed.

I think this is an excellent suggestion.  It seems to me that it
addresses all the problems I've heard raised: set the in-core label
without or writing the disk, and it's sticky.  Change the on-disk label
"behind the back of the kernel" and the in-core label is updated from
it on next first open.

The only problem I can see is, are there any ports where "the disklabel
block" is ill-defined?  I could easily imagine a vendor-OS
compatability setup where the disklabel is defined as something like
whichever block of the first 32 happens to have a valid magic number
and checksum.

Thank you.  This hadn't occurred to me, but now that it's mentioned, it
makes an extraordinary amount of sense.  (I'd be tempted to even go the
whole hog and save the whole sector, not just a checksum of it, with
the in-core label.  One sector's worth of RAM per disk spindle does not
strike me as all that much.  If you do store just the checksum, use
something stronger than dkcksum(); an XOR-everything checksum can't
detect interchanges, which could happen if, for example, two partitions
get interchanged.)

					der Mouse

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