--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 02, 2007 at 11:06:39PM +0000, David Laight wrote:
> On Tue, Jan 02, 2007 at 02:53:41PM -0800, Jason Thorpe wrote:
>=20
> The MBR extended partition is a linked list, not a tree, and is (IMHO as
> well) treated if it were just a method of splitting a large chunk of
> disk into pieces.

For what the users see, you're right. While I want to be able to support=20
overlapping partitions, the main reason for this is to help partitioning=20
tools. I think that normal usage should only see the data-containing file=
=20
systems.

> However I think you need to worry about restricting write access to
> ranges of disk blocks, and not to partitions (maybe unless the secure
> level has been raised).  In particular:
>=20
> 1) You need to be able to read and write boot information from 'partition=
s'
>    that have mounted filesystems, and (probably) be directly accesing the
>    relevant offsets from the 'entire disk' device.
>    (This means that a ufs mount must release the first 8k...)

With securelevel lowered, you can open the raw device to do this. With=20
securelevel raised, you can't do this. :-)

> 2) You needs to be able to dump directly into disk space occupied by the
>    'swap' partition of a raid volume.

Just dump to the device. The kernel can do this now, and it's not a=20
problem.

> You also don't want to be able to move the base sector of a mounted files=
ystem!
> (I've managed that one!) Nor be able (easily) to write to the disk area
> underlying a mounted filesystem.

This just means being smart about how we handle updates.

I really think we need to stick with partitions/wedges. Trying to get more=
=20
complicated can get really complex really fast.

Take care,

Bill

--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFm/2LWz+3JHUci9cRAsyEAJ9KqgX+irFtogXJMynaUeyvNP1R8ACfcYXH
kNViTiPwr9uN1Gge7hlRlNE=
=Si7A
-----END PGP SIGNATURE-----

--cWoXeonUoKmBZSoM--