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.Received on Mon Apr 04 2005 - 03:25:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC