linux-ext4 - Re: resize2fs unresponsive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 27 Feb 2016 14:56:03 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Jakob Lagerstedt <jakob.lagerstedt@....se>
Cc:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: resize2fs unresponsive

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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html