2012/3/9 Olivier Cochard-Labbé
> Hi all,
>
> once run growfs on a partition that had an UFS label, this label is
> removed and it's no more possible to re-set it with tunefs.
> Here is how to reproduce (tested on 8.3 and 9.0):
>
> mdconfig -a -t malloc -s 10MB
>
Hi all,
once run growfs on a partition that had an UFS label, this label is
removed and it's no more possible to re-set it with tunefs.
Here is how to reproduce (tested on 8.3 and 9.0):
mdconfig -a -t malloc -s 10MB
gpart create -s mbr /dev/md0
gpart add -t freebsd -s 5MB /dev/md0
new
Alex Deiter <[EMAIL PROTECTED]> wrote:
> Say me please, sometime growfs will learn to work with vinum
> volumes?
The growfs maintainers know about the problem, and are working on a
solution. We learned about that problem too late before 5.0R was due,
so since a quick fix couldn'
I get an error on 5.0-RELEASE when trying to grow vinum volume:
# growfs /dev/vinum/test
growfs: DIOCGDINFO failed
On http://www.freebsd.org/releases/5.0R/errata.html i see:
growfs(8) no longer works on vinum(4) volumes (and presumably, on
geom(4) entities) since these subsystems no longer
> It's hard to discuss what type of inconsistency there might be in an corrupted
> filesystem, compared to what growfs does. But I definitely change a lot of meta
[...]
> So the development now focusses on getting it clean on alpha, and maybe support
> the existence of snapshots
anic.
> Sorry? In single user with a readonly / and nothing else? I would have to be
> EXTREMELY unlucky to get any other access while the fs is inconsistent ;-)
>
> Seriously, I get the point (shit happens doesn't it?), but this prompts my next
> question: isn't this the
Andrea Campi <[EMAIL PROTECTED]> writes:
> I didn't state it explicitely but yes, I dropped to single user from
> multi user, remounted / to ro, fsck'ed it.
Don't do that. It doesn't work the way it's supposed to.
>I only did this because I
> must conf
In message <[EMAIL PROTECTED]>, Andrea Campi writes:
>
>Anyway, that was not my point. If I reboot into single-user, and am thus sure
>to have the / fs in a clean, consistent state, should I expect growfs to work
>in a safe way? If so, we should document it.
I think it is st
I must confess I've
never done that on FreeBSD and couldn't find a nicer way then sticking
boot_single="YES" in /boot/loader.conf... Any pointer anybody (private email)?
Anyway, that was not my point. If I reboot into single-user, and am thus sure
to have the / fs in a
Andrea Campi <[EMAIL PROTECTED]> writes:
> Sorry? In single user with a readonly / and nothing else? I would have to be
> EXTREMELY unlucky to get any other access while the fs is inconsistent ;-)
Just because you dropped to single-user mode (from multi-user, as I
recall from your previous mail)
user with a readonly / and nothing else? I would have to be
EXTREMELY unlucky to get any other access while the fs is inconsistent ;-)
Seriously, I get the point (shit happens doesn't it?), but this prompts my next
question: isn't this the same as running fsck? Maybe with growfs we h
Hi,
> A completely different question about growfs - is it fit for -stable ?
> If so could it be MFC'd (after 4.3 I suppose).
I'd be lucky, but as alpha is a supported platform, and growfs is completely
untested/ported on/to that platform I think we can't release it y
Hi,
On Sun, Mar 11, 2001 at 02:13:38PM +0100, Andrea Campi wrote:
> I was about to fill in a doc PR on this but then I thought I'm better off
> checking other people experiences...
>
> I just used growfs on my / filesystem, after shrinking the swap partition
> which just hap
On Sun, 11 Mar 2001 14:13:38 +0100
Andrea Campi <[EMAIL PROTECTED]> wrote:
AC> I was about to fill in a doc PR on this but then I thought I'm better off
AC> checking other people experiences...
A completely different question about growfs - is it fit for -stable ?
I was about to fill in a doc PR on this but then I thought I'm better off
checking other people experiences...
I just used growfs on my / filesystem, after shrinking the swap partition
which just happened to be after it. I had to do nothing magic beside dropping
to single user so as to have
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 shrink
> 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.
> *
s 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
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 rearran
> > > 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
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
>
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 th
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
Erk, I fear you mis-understand ... FreeBSD has a feature called 'VINUM',
which is a volume manager ... basically, it allows you to create RAID or
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 s
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
27 matches
Mail list logo
