From: Tomasz Chmielewski <mangoo@wpkg.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [linux-lvm] Q: Online resizing ext3 FS
Date: Wed, 12 Sep 2007 16:56:50 +0200 [thread overview]
Message-ID: <46E7FE32.7010404@wpkg.org> (raw)
In-Reply-To: <20070912163621.1f951876@slopi>
Chris Osicki schrieb:
> Hi
>
> I apologize in advance for asking a question not really appropriate
> for this mailing list, but I couldn't find a better place with lots of
> people managing lots of disk space.
>
> The question:
> Has anyone of you been using ext2online to resize (large) ext3 filesystems?
> I have to do it going from 500GB to 1TB on a productive system I was
> wondering if you have some horror/success stories.
> I'm using RHEL4/U4 (kernel 2.6.9) on this system.
Yes, I tried to online resize a similar filesystem (600 MB to 1.2 TB)
and it didn't work.
At some point, resize2fs would just exit with errors.
I tried to do it several times before I figured out what's missing;
sometimes, I interrupted the process with ctrl+c. No data loss occurred.
To do an online ext3 resize, the filesystem needs a "resize_inode"
feature. You can check the features with dumpe2fs:
# dumpe2fs -h /dev/sda1
(...)
Filesystem features: has_journal resize_inode dir_index filetype
needs_recovery sparse_super large_file
(...)
This flag is added by default only in the recent versions of e2progs
(1.39 and later AFAIR); before, it had to be specified manually. So with
RHEL4, you may be out of luck.
In the end, I had to to an offline resize.
I had this volume mirrored on another machine, so I didn't worry that
much though.
Also, to resize a filesystem of that size you would need plenty of RAM
(if you have about 1 GB RAM free, it should be just enough; otherwise,
your machine will be swapping, and the process will take longer).
Before, I tried to resize it on a machine with 256 MB and several
snapshots; resize2fs was killed because of OOM, and still, no data loss.
If you have that an old kernel, take care if you're using snapshots; I
believe they are stable only as of 2.6.22 (before 2.6.22 snapshots
needed a lot of RAM; before 2.6.18 there were problems with snapshots
removing etc.).
Would be good to add some of that info to LVM HOWTO.
--
Tomasz Chmielewski
http://wpkg.org
next prev parent reply other threads:[~2007-09-12 14:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 14:36 Q: Online resizing ext3 FS Chris Osicki
2007-09-12 14:56 ` Tomasz Chmielewski [this message]
2007-09-13 12:59 ` [linux-lvm] " Goswin von Brederlow
2007-09-13 13:07 ` Tomasz Chmielewski
2007-09-18 18:00 ` Bill Davidsen
2007-09-18 19:33 ` Goswin von Brederlow
-- strict thread matches above, loose matches on Subject: below --
2007-09-12 20:04 Stuart D. Gathman
2007-09-13 13:02 ` [linux-lvm] " Goswin von Brederlow
2007-09-13 8:09 Hiren Joshi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46E7FE32.7010404@wpkg.org \
--to=mangoo@wpkg.org \
--cc=linux-lvm@redhat.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).