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
> 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.
> *
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 ... a
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:
>
> >
> > > 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
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.
>
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 us
milar.
|
| 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 a
wrote:
> >Hi,
> >
> >Due to vinum it is no problem to add disks 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.
> >
> &
e 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 any active snapshots inside. It is foreseen to enhance growfs to
> grow mounted fil
e to vinum it is no problem to add disks 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
ten 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 availab
12 matches
Mail list logo
