From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 05:25:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E19C16A4CE for ; Mon, 4 Apr 2005 05:25:44 +0000 (GMT) Received: from thought.holo.org (h-68-166-32-19.snvacaid.covad.net [68.166.32.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0409943D45 for ; Mon, 4 Apr 2005 05:25:44 +0000 (GMT) (envelope-from bwb@holo.org) Received: from localhost (localhost [127.0.0.1]) by thought.holo.org (8.13.1/8.13.1) with ESMTP id j345PjEr037215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 22:25:46 -0700 (PDT) (envelope-from bwb@holo.org) Date: Sun, 3 Apr 2005 22:25:45 -0700 (PDT) From: Brian Buchanan X-X-Sender: brian@thought.holo.org To: Andrey Chernov In-Reply-To: <20050404051047.GA50719@nagual.pp.ru> Message-ID: <20050403221330.O36774@thought.holo.org> References: <20050404041419.GA49627@nagual.pp.ru> <20050403.222154.37240598.imp@bsdimp.com> <20050403.225310.82842428.imp@bsdimp.com> <20050404051047.GA50719@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: current@freebsd.org Subject: Re: Can't change partition table anymore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2005 05:25:44 -0000 The "SPOILING" section of the geom(4) manpage sounds like it is relevant here. From this, it sounds like attempts to open ad0 for writing should be denied if any ad0 partition is mounted, no matter read-only or read/write. Perhaps the write protection was not actually enforced until recently. It doesn't appear to be enforced by a kernel from 4 October, but is enforced on my laptop with a kernel from 12 March. - Brian Quoting: SPOILING is a special case of orphanization used to protect against stale metadata. It is probably easiest to understand spoiling by going through an example. Imagine a disk, "da0" on top of which a MBR geom provides "da0s1" and "da0s2" and on top of "da0s1" a BSD geom provides "da0s1a" through "da0s1e", both the MBR and BSD geoms have autoconfigured based on data structures on the disk media. Now imagine the case where "da0" is opened for writing and those data structures are modified or overwritten: Now the geoms would be operating on stale metadata unless some notification system can inform them otherwise. To avoid this situation, when the open of "da0" for write happens, all attached consumers are told about this, and geoms like MBR and BSD will selfdestruct as a result. When "da0" is closed again, it will be offered for tasting again and if the data structures for MBR and BSD are still there, new geoms will instantiate themselves anew. Now for the fine print: If any of the paths through the MBR or BSD module were open, they would have opened downwards with an exclusive bit rendering it impossible to open "da0" for writing in that case and conversely the requested exclu- sive bit would render it impossible to open a path through the MBR geom while "da0" is open for writing. From this it also follows that changing the size of open geoms can only be done with their cooperation. Finally: the spoiling only happens when the write count goes from zero to non-zero and the retasting only when the write count goes from non-zero to zero.