From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
Carlos Maiolino <cmaiolino@redhat.com>,
linux-ext4@vger.kernel.org
Subject: Re: new block group bitmaps not being initialized after resize!?
Date: Sat, 12 Jan 2013 23:36:15 -0500 [thread overview]
Message-ID: <20130113043615.GE19503@thunk.org> (raw)
In-Reply-To: <50F033F5.6080008@redhat.com>
On Fri, Jan 11, 2013 at 09:47:01AM -0600, Eric Sandeen wrote:
> > Zeroing the inode table but not setting the INODE_ZEROED flag
> > would not be harmful, but this seems to not be the case.
>
> we appear to be not zeroing the table, and not setting INODE_ZEROED.
> But we should have set INODE_UNINIT, or zeroed it, right?
The flag names are confusing. INODE_ZEROED means that the inode table
is not zero'ed. This is correct.
INODE_UNINIT refers to the inode allocation bitmap not being
initialized, and what we are doing is correct as well.
What we should be doing is making sure that we kick off the lazyinit
thread. So it's basically a missing call to
ext4_register_li_request(sb).
> Hum, but lazyinit will take some time to complete; in this case
> we resized, unmounted, ran fsck and everything was a mess. Even if
> we'd started lazyinit I don't think that'ts enough, because we never
> flagged the group as uninit.
But as near as I can tell, at least with the latest upstream kernel,
the flags are being set correctly. INODE_ZEROED is not being set, but
that's correct, because the inode table has not been zeroed.
The real problem was the bug which was fixed by 93f905264; previous to
this commit, the unused inode count was incorrect. My fault for not
understanding the consequences of this bug. I was thinking in terms
of the e2fsck taking too long, but of course if there were previously
valid inodes in those blocks, e2fsck would in fact go crazy. So that
commit really should have been marked cc: stable@vger.kernel.org.
Regards,
- Ted
next prev parent reply other threads:[~2013-01-13 4:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 0:07 new block group bitmaps not being initialized after resize!? Carlos Maiolino
2013-01-11 1:07 ` Eric Sandeen
2013-01-11 6:44 ` Andreas Dilger
2013-01-11 15:47 ` Eric Sandeen
2013-01-13 4:36 ` Theodore Ts'o [this message]
2013-01-13 5:26 ` Eric Sandeen
2013-01-13 13:37 ` Theodore Ts'o
2013-01-13 13:42 ` [PATCH] ext4: trigger the lazy inode table initialization after resize Theodore Ts'o
2013-01-14 13:04 ` Carlos Maiolino
2013-01-14 14:33 ` Theodore Ts'o
2013-01-14 14:42 ` Carlos Maiolino
2013-01-14 14:45 ` Carlos Maiolino
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=20130113043615.GE19503@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=cmaiolino@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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).