Thus spake The Hermit Hacker ([EMAIL PROTECTED]):
Stripe'd file systems (or concat ones) ... what growfs allows is someone
to add an n+1 drive to their RAID/Stripe and increase the size of the file
No, vinum can do this alone.
But you couldn't grow the _fs_ after that, so there was no use
On Fri, 8 Dec 2000, Alexander Langer wrote:
Thus spake The Hermit Hacker ([EMAIL PROTECTED]):
Stripe'd file systems (or concat ones) ... what growfs allows is someone
to add an n+1 drive to their RAID/Stripe and increase the size of the file
No, vinum can do this alone.
But you
Stripe'd file systems (or concat ones) ... what growfs allows is someone
to add an n+1 drive to their RAID/Stripe and increase the size of the
file
No, vinum can do this alone.
But you couldn't grow the _fs_ after that, so there was no use for
this vinum feature.
Okay, that is
I can certainly see where "cat /dev/1GBdevice /dev/10GBdevice"
situations would make a growfs useful w/out vinum...
And, removing a failing disk from the end of a a vinum concat volume
would make shrinkfs really nice.
On 12/08, Rogier R. Mulhuijzen rearranged the electrons to read:
Hi,
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
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(!).
Cool. We support the FlexRAID Virtual Sizing stuff on the AMI
controllers already, and I bet that the Mylex MORE stuff would work too.
*
In message [EMAIL PROTECTED] Goblin writes:
: I can certainly see where "cat /dev/1GBdevice /dev/10GBdevice"
: situations would make a growfs useful w/out vinum...
:
: And, removing a failing disk from the end of a a vinum concat volume
: would make shrinkfs really nice.
I recently did that
a growfs(8)
for FreeBSD. Currently we can only grow unmounted file systems (in a clean
state) without any active snapshots inside. It is foreseen to enhance growfs to
grow mounted file systems as well, and handle active snapshots correctly.
This requires some infrastructure which is then only available
and grow your volumes but up to
now you couldn't easily make use of that new space for a file system, except
using sequence of ufsdump/newfs/ufsrestore or something similar.
Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8)
for FreeBSD. Currently we can only grow
.
Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8)
for FreeBSD. Currently we can only grow unmounted file systems (in a clean
state) without any active snapshots inside. It is foreseen to enhance growfs to
grow mounted file systems as well, and handle active
easily make use of that new space for a file system, except
using sequence of ufsdump/newfs/ufsrestore or something similar.
Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8)
for FreeBSD. Currently we can only grow unmounted file systems (in a clean
state) without
.
|
| Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8)
| for FreeBSD. Currently we can only grow unmounted file systems (in a clean
| state) without any active snapshots inside. It is foreseen to enhance growfs to
| grow mounted file systems as well, and handle active
12 matches
Mail list logo
