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

On Fri, Apr 08, 2005 at 07:23:12PM -0700, Marcel Moolenaar wrote:
> 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.

I don't mean overlapping. I can shrink whole foreign (inactive) filesystem 
to the swap file size, then expand it back after use, both operations are 
in-core and no overlapping created.

> 2.
> If FreeBSD can mount the file system, you don't need any partition 
> tricks
> to create more storage. Use md(4).

I know. Let's assume, FreeBSD can't. To be more precise, just one example: 
formally FreeBSD can mount NTFS, but in reality NTFS support is so badly 
written so can damage things. F.e. I remember one restriction: NTFS 
partition must be small, otherwise there overflow happens somewhere inside 
ntfs code with lots of kernel printfs and lots of files are not visible.

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

If there will be GEOM class especially for such type of things, there is 
no difference, because it is equivalent to in-core editing. But I don't 
have much expectation of further GEOM development, looking at nowdays 
phk's reaction.

> Point 3
> above is an indication that there is use for soft-slicing. Soft-slicing 
> has
> nothing to do with disk partitions.

To emphase: soft-slicing of foreign filesystem. It depends on 
implementation. It can be related or not. If the same functionality 
provided with the same complexity level by another way, there is no 
difference from usage point of view.

-- 
http://ache.pp.ru/