linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Brad Campbell <lists2009@fnarfbargle.com>
Cc: Azat Khuzhin <a3at.mail@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: Online resize issue with 3.13.5 & 3.15.6
Date: Mon, 28 Jul 2014 22:46:51 -0400	[thread overview]
Message-ID: <20140729024651.GA14680@thunk.org> (raw)
In-Reply-To: <53D3B12C.5040703@fnarfbargle.com>

On Sat, Jul 26, 2014 at 09:46:20PM +0800, Brad Campbell wrote:
> Fast forward 12 months and
> I've added 2 drives to the array and bumped up against this issue. So it was
> initially 4883458240 blocks. It would have been created with e2fsprogs from
> Debian Stable (so 1.42.5).

Confirmed; debian stable's mke2fs version 1.42.5 does the wrong thing
if you do:

   mke2fs -t ext4 -O 64bit,resize_inode /mnt/foo.img  19T

It creates a file system which is has a resize_inode which --- well,
is in a format that the kernel isn't capable of handling and which is
not something that was originally intended.  The interesting thing is
that resize2fs 1.42.11 is apparently able to handle resizing the above
file system created with mke2fs 1.42.5.

Mke2fs 1.42.12 will avoid creating a resize_inode for file systems >
16T, so this situation doesn't arise.

I need to take a closer look to see if there's some way I can teach
the kernel to be able to deal with this file system, but for now, you
can work around it by using tune2fs to remove the resize_inode, and
after running e2fsck and remounting the file system, the on-line
resize will work correctly.

Cheers,

					- Ted

  parent reply	other threads:[~2014-07-29  2:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-20 11:26 Online resize issue with 3.13.5 & 3.15.6 Brad Campbell
2014-07-21  1:03 ` Brad Campbell
2014-07-25  4:33   ` Brad Campbell
2014-07-25  8:13   ` Azat Khuzhin
2014-07-25 11:44     ` Brad Campbell
2014-07-25 14:07       ` Theodore Ts'o
2014-07-26  3:31         ` Brad Campbell
2014-07-26  4:12           ` Brad Campbell
2014-07-26  7:04             ` Azat Khuzhin
2014-07-26  7:45           ` Azat Khuzhin
2014-07-26 12:45           ` Theodore Ts'o
2014-07-26 12:57             ` Azat Khuzhin
2014-07-26 13:46             ` Brad Campbell
2014-07-26 13:56               ` Theodore Ts'o
2014-07-29  2:46               ` Theodore Ts'o [this message]
2014-07-29  8:00                 ` Brad Campbell

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=20140729024651.GA14680@thunk.org \
    --to=tytso@mit.edu \
    --cc=a3at.mail@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=lists2009@fnarfbargle.com \
    /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).