linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: linux-ext4@vger.kernel.org
Cc: sandeen@redhat.com
Subject: new block group bitmaps not being initialized after resize!?
Date: Thu, 10 Jan 2013 22:07:11 -0200	[thread overview]
Message-ID: <20130111000711.GA2490@andromeda.usersys.redhat.com> (raw)

Hi guys,

I'm working on a Fedora bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=852833)
together with Eric and we found that the problem described on the bugzilla
happens when the commit 93f9052643 is not applied, which is the case of the
Fedora 16 kernel being discussed there.

Although we already found the solution to the problem in the commit above,
looking through the commit have raised some questions regarding to the bitmap of
the newer block groups added to the FS after it is extended.

The newer block groups do not have flags ITABLE_ZEROED and INODE_UNINIT set,
even when 'lazy_itable_init' is enabled.

Without this commit, inode stale data might be exposed and also makes fsck
complain about all inodes of the newer block groups.

The question is, are these flags expected to not be found on these newer block
groups or they should be set?

The lack of these flags on newer block groups is an expected behaviour or is
something that should be fixed?

FWIW, in the old ext4_group_add(), we added EXT4_BG_INODE_ZEROED flag to the
bg_flags, also, I did some tests here and the lack of these flags look to not be
affecting filesystem integrity, i.e. new inodes can be properly allocated, which
sounds that these uninitialized inodes/bitmaps are set to be initialized as soon
as a first inode is allocated on these new BGs.


Anything else I'm missing Eric?

Cheers,
-- 
Carlos

             reply	other threads:[~2013-01-11  0:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-11  0:07 Carlos Maiolino [this message]
2013-01-11  1:07 ` new block group bitmaps not being initialized after resize!? Eric Sandeen
2013-01-11  6:44   ` Andreas Dilger
2013-01-11 15:47     ` Eric Sandeen
2013-01-13  4:36       ` Theodore Ts'o
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=20130111000711.GA2490@andromeda.usersys.redhat.com \
    --to=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).