Date: Fri, 8 Apr 2005 19:23:12 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Andrey Chernov <ache@nagual.pp.ru> Cc: current@FreeBSD.ORG Subject: Re: GEOM architecture and the (lack of) need for foot-shooting Message-ID: <f2da909a45f56ec44a9e0cbe85b18107@xcllnt.net> In-Reply-To: <20050408234927.GD37182@nagual.pp.ru> References: <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> <20050408191045.GA10743@ns1.xcllnt.net> <20050408210453.GA32421@nagual.pp.ru> <20050408223335.GA11503@ns1.xcllnt.net> <20050408234927.GD37182@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 8, 2005, at 4:49 PM, Andrey Chernov wrote: > 2) Why in-core editing is needed: live example. Imagine you have disk > with > some OS installed with swapfile placed first and you know its size. > Lets > assume you temporary needs some file space. You can edit in-core table > of > that disk, putting partition just inside that swapfile space range. > Then > you can in-core label, newfs swapfile itself, put some files there for > what they temporary purpose was and then reboot without initiating > in-core/on-disk sync, of course. _Nothing_ will be written to on-disk > partition/label in my variant, so any existen data there will be > untouched. 1. If it's a swap *file*, it must live in a file system and thus in a partition. You cannot, by your own argument, create an in-core partition that overlaps the partition that holds the file system in which the swap file lives. If it's a swap partition, you can just use it. 2. If FreeBSD can mount the file system, you don't need any partition tricks to create more storage. Use md(4). 3. If FreeBSD can't mount the file system, then there's a provider without consumers in the GEOM world. A yet to be written GEOM class can be used for ad-hoc, volatile slicing of a provider. Writing such a GEOM class is much more useful, because it's generic and better fits the design of GEOM. Ergo: I remain unconvinced. No in-core partition editing is needed. Point 3 above is an indication that there is use for soft-slicing. Soft-slicing has nothing to do with disk partitions. -- 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?f2da909a45f56ec44a9e0cbe85b18107>