[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150811224718.GD20658@thunk.org>
Date: Tue, 11 Aug 2015 18:47:18 -0400
From: Theodore Ts'o <tytso@....edu>
To: Johan Harvyl <johan@...vyl.se>
Cc: linux-ext4@...r.kernel.org
Subject: Re: resize2fs: Should never happen: resize inode corrupt! - lost key
inodes
On Tue, Aug 11, 2015 at 08:15:58PM +0200, Johan Harvyl wrote:
>
> I recently attempted an operation I have done many many times before, add a
> drive to a raid array followed by offline resize2fs to expand the ext4fs on
> it.
If you've read the old threads, you'll note that online resize is
actually safer (has proven to have had less bugs) than offline
resize, at least with respect to big ext4 file systems. :-/
I'm not aware of any offline resize with 1.42.13, but it sounds like
you were originally using mke2fs and resize2fs 1.42.10, which did have
some bugs, and so the question is what sort of might it might have
left things.
It looks like you were resizing the file system from 18TB to 22TB.
There shouldn't have been a resize inode if the file system was larger
than 16TB, and so it sounds like is that was what tickled this error message:
> # resize2fs /dev/md0
> Should never happen: resize inode corrupt!
This was after most of the resize work has been done, so the question
is what we need to do to get your file system up and running again.
What does "e2fsck -fn /dev/md0" report?
Hopefully "e2fsck -fy /dev/md0" will fix things for you, but if you
haven't made backups, we should be careful before we move forward.
- 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
Powered by blists - more mailing lists