Re: GEOM architecture and the (lack of) need for foot-shooting

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_at_xcllnt.net