Date: Fri, 8 Apr 2005 12:10:45 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Andrey Chernov <ache@nagual.pp.ru>, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@FreeBSD.ORG Subject: Re: GEOM architecture and the (lack of) need for foot-shooting Message-ID: <20050408191045.GA10743@ns1.xcllnt.net> In-Reply-To: <20050408071439.GA7431@nagual.pp.ru> References: <21342.1112914675@critter.freebsd.dk> <09c6072206df99be25e345b7e13354f5@xcllnt.net> <20050408050405.GA5203@nagual.pp.ru> <19f3c4e12937f581f7420bc841a11810@xcllnt.net> <20050408055144.GA6147@nagual.pp.ru> <b1fbaa6b2ea41e893ae1f3c94d49c2ee@xcllnt.net> <20050408063138.GA6884@nagual.pp.ru> <4fc54539e2b80a0718c8d21be862c379@xcllnt.net> <20050408071439.GA7431@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 08, 2005 at 11:14:39AM +0400, Andrey Chernov wrote: > On Thu, Apr 07, 2005 at 11:51:03PM -0700, Marcel Moolenaar wrote: > > >F.e. one can temporary remove whole BSD partition for other OS better > > >install, then re-create it again inside other OS. > > > > I don't see how this is illegal. It's exactly the thing you don't want > > to prevent for no good reason. It's a dangerous operation if you don't > > know what you're doing but other than that can be a real handy feature. > > I mean it becomes illegal when synced from on-disk to in-core - whole > working space disappearse. This is example why on-disk->in-core sync is > dangerous while in-core->on-disk is always safe. Slow down, breath but most of all: think. You're not making much sense. Compare both by applying the same change to both of them. So, let's remove a BSD partition and for the heck of it, the one containing the root file system: o Editing the in-core data is an immediate show-stopper. You immediately pull the root file system from under the running OS. Not good, no matter what the failure mode. o Editing the on-disk data is harmless as long as you don't sync in the in-core data with the disk. It's a showstopper when you do sync. The advantage is clear. You can have non- atomic operations that are dangerous, harmful or inconsistent when partly applied, but that may yield a harmless change when fully completed. The same applies to any and all changes. > > But if a file system goes beyond the boundaries of a partition, you > > don't need to increase the partition to get to the files. They were > > written there despite the partition boundaries. Not to mention that > > you can just read the adjacent partition to read the raw sectors. > > No, your example isn't a good one. > > Oh, this is real life example. And I mean FAT32 or NTFS (I don't remember > right now, one year passed) as a filesystem, not UFS. And I mean not > recover files goes beyound (there just was incorrect sector numbers, not > data written) but old files. The problem was that it simple not mounted by > Windows without such partition surgery. "Unmountable boot volume". I see. Do you think it's wise to design for broken file system implementations? Don't you think that it's fair to assume that whatever you write to a partition, it will not cross its bounds? I mean, if an OS is writing to a file system and is messed up enough to completely go out of bounds then the data in the adjacent partitions is already corrupted *or* there partition was surrounded by free space. In the second case you don't have a proble, but in the first case you might as well back up the adjacent partitions and nuke them, because they have already been corrupted. You need to do a lot more surgery than you can probably handle with existing tools. > > Why would you ever allow a partition table to contain overlapping > > partitions? > > For surgery purposes. Consider this like fsdb(8). I look at it from a much more elementary point of view: if you do surgery that crosses partition boundaries, then you need to be doing raw disk access and no partition table is prohibiting you therein. Why then is there a need to change the partition table? > > but never in the on-disk table by itself or in the in-core data by > > itself. > > Right? > > Not quite right. I want inconsistencies in on-disk table (with warnings > and (Y/N) confirmations etc.) because of surgery. But not in the in-core > table, because it is live running and could lead only to more chaos. I see. I think this is another point on which we differ: you want to be able to edit the partition table to accomodate certain kinds of surgery. I think such surgery doesn't need support from the tools as it goes well beyond the functionality of partitioning. Interesting... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050408191045.GA10743>