Re: disklabel -W now seems to not work(?)
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
Re: disklabel -W now seems to not work(?)
Wow. Okay. On Mon, 6 Dec 1999, Bruce Evans wrote: 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 I was being polite... :-) 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: ... (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. The reason I brought this all up is that XX0 access would not work for me. The disk had a dangerously dedicated label, but I wanted to overwrite the front of the disk. Impossible. I've noticed this also in the case where you have slices but want to go to a dangerously dedicated label- no can do. Hence a "Well, gee, let's see if disklabel -W will help". Nope. So, what's the answer about what to do? I sure wouldn't want to leap in and 'fix' it because I don't have a good feel for the ins and outs of this stuff here (odd- I usually have a strong sense of knowing what's right, but this house of cards gives me the creeps). I have a hacked dd that works for me, but this can't be the right general solution. Probably if I added my disk tester into the test suites, that would allow one to force this (although by default the tester I use always skips label areas). -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
On Sun, 5 Dec 1999 10:15:07 -0800 (PST), Matthew Jacob [EMAIL PROTECTED] said: So, what's the answer about what to do? exec 3/dev/xx0 dislabel -W xx0 spam /dev/xx0 exec 3- -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
Good, but like just having popcorn for dinner, somehow unsatisfying... On Sun, 5 Dec 1999, Garrett Wollman wrote: On Sun, 5 Dec 1999 10:15:07 -0800 (PST), Matthew Jacob [EMAIL PROTECTED] said: So, what's the answer about what to do? exec 3/dev/xx0 dislabel -W xx0 spam /dev/xx0 exec 3- -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
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 This was the topic of my "Fscking disklabel crap" mail to freebsd-alpha on Fri, 26 Nov 1999 11:56:59 -0800, which nobody responded to. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
On Mon, Dec 06, 1999 at 02:50:43AM +1100, Bruce Evans wrote: (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). How do we fix this problem? I keeps from from ``dd if=/dev/da1 of=/dev/da2'' ?? I was very peeved at having to put the disks on a Solaris box to do such a normal Unix task. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
Sorry- I missed it. I was in Kaui. On Sun, 5 Dec 1999, David O'Brien 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 This was the topic of my "Fscking disklabel crap" mail to freebsd-alpha on Fri, 26 Nov 1999 11:56:59 -0800, which nobody responded to. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
The reason I brought this all up is that XX0 access would not work for me. The disk had a dangerously dedicated label, but I wanted to overwrite the front of the disk. Impossible. I've noticed this also in the case where you have slices but want to go to a dangerously dedicated label- no can do. The second case should work even on alphas unless the first slice already begins at offset 0. The labels and their write protection will go away when the slice table for the dangerously dedicated disk is written (and synced by closing all minors on the disk or by calling the ioctl for this as in sysinstall). At worst you resurrect an old label if you didn't clear it before changing the slice table. So, what's the answer about what to do? I sure wouldn't want to leap in and 'fix' it because I don't have a good feel for the ins and outs of this stuff here (odd- I usually have a strong sense of knowing what's right, but this house of cards gives me the creeps). The correct fix for the immediate problem of write protection on XX0 is to remove the alpha ifdefs in subr_diskslice.c and then properly fix the bug in the alpha sysinstall which caused them to be hacked in. sysinstall and libdisk have an alarming number of __alpha__ ifdefs. The dangerously dedicated case seems to be required, so it should be possible to use XX0c instad of XX0 for almost everything. The problem is probably that XX0c doesn't exist until you write suitable magic to XX0 (XX0c is the 'c' partition on the first BSD slice, so it doesn't exist if there are no BSD slices). For the i386 the boot sector contains suitable magic. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
On Sun, 5 Dec 1999, David O'Brien wrote: On Mon, Dec 06, 1999 at 02:50:43AM +1100, Bruce Evans wrote: (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 How do we fix this problem? I keeps from from ``dd if=/dev/da1 of=/dev/da2'' ?? I was very peeved at having to put the disks on a Solaris box to do such a normal Unix task. See other replies. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabel -W now seems to not work(?)
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. Before I go tracking this down as a bug, is it? 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? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
