Subject: Re: wedges and what does that mean?
To: Bill Studenmund <firstname.lastname@example.org>
From: Johnny Billquist <email@example.com>
Date: 09/05/2006 22:05:58
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
>> The actual width of the size and offset is hardly a reason to say it's
>> different. Is the information about wedges not stored on the disk? How
>> do you find them in that case?
>> I'm probably dense, but this answer made it look no different from a
>> partition, except the fact that they were 64-bit values. Which is nice,
>> 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
> struct disklabel. And struct disklabel is an on-disk format. So there's no
> 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 defined
> them. So you don't need a struct disklabel, or struct part_map_entry, or
> any other struct.
So? You still need something. As far I can understand so far, the only
difference is that you've generalized partitions to deal with multiple
ways of describing the partition. Can't really see the big need for
that, but then again, there are several things in the system today that
I'm not sure I see the point of.
> Since there's a disconnect between the on-disk representation and the
> in-kernel one, you can map anything into a wedge.
This is one thing I'm having a real hard time understanding.
AFAIK, nothing prevents you to put just about anything in a partition today.
> Another part of the conceptual plan is that we move partition reading out
> of the kernel into userland. The kernel only NEEDS to be able to find the
> root partition, then userland can find all the rest. As a convenience, you
> can (according to the plan) add support for different partitioning schemes
> in the kernel.
That all sounds fine, but why?
> We aren't there yet, and things don't work according to the plan. But
> we're getting there. :-)
Ok. I guess someone must feel the need then.