* Re: resize2fs unresponsive
2016-02-26 13:33 resize2fs unresponsive Jakob Lagerstedt
@ 2016-02-27 19:56 ` Theodore Ts'o
0 siblings, 0 replies; 2+ messages in thread
From: Theodore Ts'o @ 2016-02-27 19:56 UTC (permalink / raw)
To: Jakob Lagerstedt; +Cc: linux-ext4@vger.kernel.org
On Fri, Feb 26, 2016 at 02:33:38PM +0100, Jakob Lagerstedt wrote:
> Dear developers,
>
> We started a resize2fs (version 1.42.9) on Ubuntu 14.04 against a unmounted raid.
>
> It has taken a long time and not much seems to be happening. We have
> not found any answers to these questions in the documentation and
> conflicting answers from forums.
So a couple of things. resize2fs using a mounted raid is safer than
an unmounted filesystems. There were bugs with older versions of
resize2fs that could cause corruption, specifically with doing
resize2fs for large file systems while unmounted. So I strongly
recommend that you not try to do unmounted resize2fs except with the
very lastest version of e2fsprogs (1.42.13).
Unfortunately, killing an resize2fs while unmounted while _usually_
safe, *can* cause damage while it is relocating the inode table
blocks. This normally wouldn't happen, since we reserve space to
avoid needing to do this, but without knowing how big the file system
was when it was originally created, and how big you are trying to
resize it to. If you send it an interrupt signal (e.g., type
control-C) it will try to stop at a clean point. But if you send it a
kill -9 or there is a power failure while it is relocating the inode
table, you can lose data. (This is not a problem if you use resize2fs
while it is mounted, since when it is mounted it uses the journal to
make sure things stay consistent even if the sytem crashes.)
Given the balance of risks, it's probably better to interrupt it with
a control C, and then run e2fsck on the file system afterwards.
> Can the resize be restarted if we kill it?
No, it can't be restarted.
- Ted
^ permalink raw reply [flat|nested] 2+ messages in thread