On Wed, Nov 15, 2006 at 12:06:20PM +0100, Alexander Hall wrote:
> Joachim Schipper wrote:
> >On Fri, Nov 10, 2006 at 04:10:54PM -0600, Damian Wiest wrote:
> >>I've had the misfortune of running AIX for a short time and am aware of
> >>how Veritas Volume Manager encapsulates disks, but what's the
> >>equivalent in OpenBSD? One benefit of those systems is that they allow
> >>you to resize filesystems on the fly, which is helpful if you're not
> >>sure how much space you're going to need. I sometimes end up performing
> >>two installs. The first one lets me see how much space the OS
> >>distribution is likely to occupy and I then use those numbers when I redo
> >>the install.
> >
> >If you want to do the same in OpenBSD, allocate the maximum number of
> >partitions and run ccd devices over appropriate subsets of the
> >partitions. (Note growfs(8); there is no shrinkfs, though.)
> >
> >If this is not granular enough, add one ccd device per partition, and
> >parition that one again [1]. This setup would allow dividing a disk in
> >15x15 = 255 not necessarily equally big slices, which Should Be Enough
> ^^^^^^^^^^^ oops
Yet another mathematician that can't count. Oh well, I'm doing algebra
anyway - counting is for engineers. ;-)
> >For Everyone. (If not, repeat.)
>
> Interesing thought. Fragmented filesystems (not just files). Probably
> horrible in many ways and easy to make mistakes, but still interesting.
>
> But why not just start with a reasonably sized partition per ccd and
> then add additional partitions (of varied sizes) when needed? I see no
> need to predefine the partitions. Then, should you run out of
> partitions, you could make the last one (p?) use the rest of the disk
> and split it using the technique mentioned above.
This would, indeed, work. Which is not to say it's necessarily a good
idea, of course... though I must admit that, outside of being fugly and
having some minor overhead, I find it hard to spot the downsides.
Joachim
