From owner-freebsd-current Sun Dec 5 7:51: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7B3A114BD0 for ; Sun, 5 Dec 1999 07:51:01 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id CAA05610; Mon, 6 Dec 1999 02:56:04 +1100 Date: Mon, 6 Dec 1999 02:50:43 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Matthew Jacob 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 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message