From owner-freebsd-current Sun Dec 5 10:13:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A7281153F3 for ; Sun, 5 Dec 1999 10:13:53 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA13944; Sun, 5 Dec 1999 10:15:08 -0800 Date: Sun, 5 Dec 1999 10:15:07 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: disklabel -W now seems to not work(?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message