On Wed, 18 Dec 2002, Frank van der Linden wrote:

> I think I mostly agree with what you're proposing, except that you seem
> to think that using on-disk partitions excludes 'LVM' type usage that
> uses config files.

Yes, I do, for a given disk. If we use a partition editor to lay them out,
they are partitions, and we should act like it.

If we want to go the LVM route (and I think WE DO and I'd LOVE it), we
give the whole disk to the LVM route. My thought is that an LVM'd disk
would have no defined partitions in the diskpart method.

To me, they (partitioning schemes and LVMs) are like Apples and Oranges.
We have Apples, we want Oranges. Let's get Oranges, not some apple-orange-
mash-mix that tastes like both and neither.

> The basic idea is that some userspace program pushes partition info into
> the kernel, and the kernel assigns this to the appropriate device nodes.
> If you simply reserve a class of device nodes as the 'no partition' type,
> people can go the config file route as well. If they want to, why not?
> It can certainly be useful. We won't use it by default, I suppose, but
> giving people the option is trivial. The only difference is that the
> partition info happens to be in a config file, instead of in an on-disk
> format someplace.

If I understand you, you're suggesting diskpart is fine, but let's have a
way to also do the extent business. Ok.

But why?

The big user I can see for the extent usage is a simplistic LVM. But it
lacks some of the big features of an LVM. For one, you can't arbitrarily
grow one of these things, and that's what saved my butt as an admin on
occasion. :-) Also, how do we handle the feature most LVMs have of
auto-mirroring?

> Getting back to the original plan, I think that there are 2 things we
> can start doing, since they will be needed in all cases under discussion:
>
> 	1) Write a library and tool that knows about all partition
> 	   formats, and can manipulate them, in both big- and little
> 	   endian byteorder. As a sample usage, write a program that
> 	   grovels a disk, and spits out offsets and types of partitions.
> 	   (mbrlabel can be used for this, for example, other platforms
> 	   may have other tools).
>
> 	2) Bump daddr_t to 64 bits in the kernel, and make that work.

Agreed!

Take care,

Bill