>> What I mostly want to say is, there's a quick-fix kludge possible
>> right now.  Take a big partition and turn it into a one-element ccd,
>> and (sub)partition that.
> Doesn't scale very well.

No, it doesn't scale well at all.  Nor do I offer it as anything
approximating a real fix to the problem.  I simply offer it as
something that might help some (some, not all) people who are feeling
cramped by the current limit.

> If you've already used ccd to glue four 80gig disks (or 5, with
> raidframe) into a 320-gig volume, how many vnds-inside-vnds do you
> need to get back to reasonable cpg and block/fragment size?

Well, ccds-inside-ccds; vnds-inside-vnds loses even worse because the
filesystem gets in the way at each layer.

How many?  Each layer gives you a factor of six (eight, minus c and d -
you can't do this with a partition that begins at offset zero, but the
first 8K doesn't have to belong to any partition except d - I'm not
entirely convinced the c partition can't be coaxed into use, but let's
not get too experimental here).

6^2 = 36; 320/36 = 8.8889-.

6^3 = 216; 320/216 = 1.48148+.

If you're satisfied with partitions averaging about 9G, two layers.  If
you want to go down to under 1.5G, three layers.  Four layers will take
you down to 252.84-M partitions.  Etc. :-)

> What does that do to your disk throughput?

Measure it and find out. :-)  But if you're shattering your 320G ccd or
raid into pieces that small, are you an environment that's likely to
care?

Not that it really matters; I make no claims about this kludge being
suitable for all - or even any - environments.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B