On Sat, 4 Dec 1999, Matthew Jacob wrote:
> It seems that in the latest running around with things, disklabel -W
> doesn't seem to quite work, at least on the alpha- it seems to set the
> label writable, but the next attempt to open the disk sets the label area
> non-writable again.
It hasn't quite worked for 5 years now (except for additional not workage
on alphas). There are layers and layers of bugs and features which
combine to make it very difficult to write the label sector except in the
normal way:
(1) All labels on the disk go away and are reconstructed from scratch
on first (re)open ("first open" here means "first on the disk to
go from the state with no minors on the disk open to the state with
>= 1 minors open"). In particular, the settings of all label write
protection flags go away and then com back as "set". Things are done
this way in an attempt to make removable media work right even if
the driver doesn't support it. Drivers that support removable media
also make all the labels go away when the media goes away.
Workaround: keep some minor on the disk open while using disklabel -W.
(2) The label i/o snooping code checks the validity of labels written to
the label sector. You can't write an invalid label to the label
sector even if the sector is not write protected. Things are done
this way because it's the normal mode of operation for disklabel -r
to write and read slightly invalid labels (with relative offsets
instead of absolute). The label i/o snooping code watches for these
accesses and fixes up the labels.
Workaround: duplicate the existing label in the output.
(3) The label snooping code is not smart enough to fix up the labels
properly for copying slices on the same disk, even if the partition
tables are apparently identical. Similarly for copying any partition
which contains the label.
Workaround: copy everything up to the label sector and everything
after the label sector separately. Then use disklabel(8) to adjust
the label sector.
(4) Write protection and i/o snooping of labels is half-intentionally
broken for i/o to the whole disk slice (e.g., /dev/da0). It can be
used to work around bugs and features in the write protection and
snooping. E.g., the only way to clear a label is to write garbage
over it using the whole disk slice. Writing garbage over it using
an ordinary slice is prevented by the i/o snooping code.
(5) The whole disk slice was broken for alphas in rev.1.63 of
subr_diskslice.c, by putting a label on it if the underlying disk
contains a label. The underlying disk contains a label in the
"dangerously dedicated case". If there is a label, then it is
initially write protected, and always snooped on. This closes
the back door in (4).
> Secondly, how do people feel about having dd(1) use the DIOCWLABEL
> argument to enable writing the label area of the disk if the output is a
> disk and there is no offset from zero?
Unwell. The whole disk device (e.g., /dev/da0) is already entirely
write-enabled and unsnooped. except as in (5). Write protection of
labels should continue to apply to partitions (e.g., /dev/da0a and
/dev/da0c) even if the partitions start at offset 0.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
