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

On Tue, Sep 05, 2006 at 10:05:58PM +0200, Johnny Billquist wrote:
> Bill Studenmund skrev:
> >On Mon, Sep 04, 2006 at 01:58:31PM +0200, Johnny Billquist wrote:
> >>So, what are you saying?
> >>
> >>Are wedges just partitions with another name, or is there really a=20
> >>difference?
> >>The actual width of the size and offset is hardly a reason to say it's=
=20
> >>different. Is the information about wedges not stored on the disk? How=
=20
> >>do you find them in that case?
> >>
> >>I'm probably dense, but this answer made it look no different from a=20
> >>partition, except the fact that they were 64-bit values. Which is nice,=
=20
> >>but it don't really make them any different.
> >
> >Most of the differences are conceptual.
> >
> >The thing about our partitions is that they really really are entries in=
 a=20
> >struct disklabel. And struct disklabel is an on-disk format. So there's =
no=20
> >way to change "partition"s without changing the on-disk format.
> >
> >Thus a conceptual change to get us out of the difficulty.
> >
> >wedges are partitions separated from the partitioning scheme that define=
d=20
> >them. So you don't need a struct disklabel, or struct part_map_entry, or=
=20
> >any other struct.
>=20
> So? You still need something. As far I can understand so far, the only=20
> difference is that you've generalized partitions to deal with multiple=20
> ways of describing the partition. Can't really see the big need for=20
> that, but then again, there are several things in the system today that=
=20
> I'm not sure I see the point of.

No, the big thing is that we break the kernel of the concept that it knows=
=20
the on-disk partitioning format. And we break all our methodologies of=20
this concept. In the old world order, you shoved a disklabel on the disk,=
=20
updated the in-core one, then wrote the in-core one to disk. New way you=20
just update the disk and tell the kernel what it should do next.

Another thing we do differently is that we now have the concept that a=20
wedge has a name.

Also, since we break the kernel representation from the on-disk one, we=20
can grow the in-kernel one to 64 bits w/o changing the on-disk format.

> >Since there's a disconnect between the on-disk representation and the=20
> >in-kernel one, you can map anything into a wedge.
>=20
> This is one thing I'm having a real hard time understanding.
> AFAIK, nothing prevents you to put just about anything in a partition tod=
ay.

Yes, but today that partition exists only within a struct disklabel. No=20
struct disklabel, no partition.

> >Another part of the conceptual plan is that we move partition reading ou=
t=20
> >of the kernel into userland. The kernel only NEEDS to be able to find th=
e=20
> >root partition, then userland can find all the rest. As a convenience, y=
ou=20
> >can (according to the plan) add support for different partitioning schem=
es=20
> >in the kernel.
>=20
> That all sounds fine, but why?

Read the treads on wedges. Charles first discussed them back in 1998. Also=
=20
look at the threads on changes to partitioning tools to see more why they=
=20
irritate people so.

> >We aren't there yet, and things don't work according to the plan. But=20
> >we're getting there. :-)
>=20
> Ok. I guess someone must feel the need then.

Well, struct disklabel won't break 2 TB, so yes, we feel the need. :-)

Take care,

Bill

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

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

iD8DBQFE/ig8Wz+3JHUci9cRArB5AJ9uFB+s89+XgRZ8P2GIvctnwsE23QCfWB1N
SJNyt463324pqcrlyvTf0/0=
=qcmq
-----END PGP SIGNATURE-----

--poemUeGtc2GQvHuH--