Skip site navigation (1)Skip section navigation (2)
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>