>> (sigh, really wish ccd would behave more sensibly; having to lie
>> about cylinder size to avoid wasting space is a pain.)
> It's not really lying about cylinder size at all.  The reason you
> offset one cylinder [...is...]

Yes, I know why you offset by one cylinder.  What I mean is, I wish you
didn't have to waste a whole cylinder of space.

My remark was pointing out that with the current scheme, if you wish to
cut down on the lost space, you have to relabel the disk with a label
that claims smaller cylinders and more of them than the disk really
has.  My preferred solution would be for ccd to skip the first sector
(perhaps the first 8K) of a component, when that component partition
begins at offset zero.  I would even be satisfied if it always skipped
the first sector (or 8K).

>> I wrote a program ("fsresize") which can resize filesystems, [...]
> Note, we've had this thread before (and beat it into the ground,
> actually :-)

:-)

> Mouse's fsresize will only work if you add components to the *end* of
> a *serially concatenated* volume (no interleave).

Well, yes.  It would be possible to shuffle blocks around so you could
add a disk to a striped ccd and not lose the contents; indeed, it may
be worth doing, because if you're using a ccd, you likely don't have
enough temporary space to do the dump/re-ccdconfig/restore thing.

Of course, like fsresizing a concatenated ccd, it's not something you
could do hot without hacking some sort of filesystem isolation.  (Which
actually may be possible, at least wrt the ccd - there's no reason one
couldn't have an ioctl for a ccd which makes it freeze requests while
you reconfig and presumably shuffle stuff underneath it - this'd work
for adding a new member and re-interleaving, but to make it work for
growing or shrinking you'd have to put it at a much higher level, with
an implicit "mount -o reload"....)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu