In an attempt to resolve that discussion:
> > > No, vinum can do this alone.
> > > But you couldn't grow the _fs_ after that, so there was no use for
> > > this vinum feature.
Exactly that was the motivation for writing that utility
> >Okay, that is what I said ... "add an n+1 drive to ... and increase the
> >size of the file system" ...
... which means basically the same :-)
> I still don't see why growfs wouldn't work on a non-vinum volume. It's just
> a manipulation of the FS, not of the underlying device. But let's leave
> this for the makers of growfs to answer shall we =)
again correct, technically it is possible to use growfs on ANY object which
has a ufs filesystem structure:
vinum volume, a partition on a disk, ccd device, even a flat file
provided, that there is some space on the end(!) of that medium which is
not yet taken by the ufs structures.
So you can use it either with hardware RAID controllers which allow for
non destructive extending of the size of existing volumes at the end(!).
As well you can use it for vinum volumes. Currently this is only possible for
mirrored plexes of any kind, or unmirrored concatenated plexes.
All other devices cant be changed without destroying the contents.
And you can just give some space in the partition table (disklabel) to an
existing partition (at its end) and let the filesystem grow within that bound.
A shrinkfs is NOT written. The design allows for writing it, but we currently
consider other features much more important, like
* growing a mounted filesystem
* handling file systems with active snapshots is in
* grow in a way that we are always safe to loose the power during the
growing (softdep concept)
* handle byteorder correct on non intel platform (we don't have any alpha
hardware but think ufs on alpha is not ufs on intel)
* provide the current funktionality on FreeBSD-4 at least, maybe FreeBSD-3
Die Netz-Werker GmbH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message