linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).