linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Subject: [PATCH 0/2 -v2] Clean up bitmap loading
Date: Mon,  6 Feb 2012 14:54:42 -0500	[thread overview]
Message-ID: <1328558084-19430-1-git-send-email-tytso@mit.edu> (raw)

As it turns out we can't remove the forced initialization of the block
bitmap when initializing the inode bitmap; e2fsck will complain because
it explicitly checks for this condition.  Thanks to Rakish Iyer at
Google for finding this through his testing effort (debugging sucks;
testing rocks!) and Curt Wohlgemuth for his analysis of the test failure
and finding its cause.

I've removed the first patch that was in the previous version of this
patch series for now, and will be patching e2fsprogs to eliminate this
check.  Since we can't guarantee that people will be running a
sufficiently new version of e2fsprogs, we'll probably have to keep the
block bitmap initialization in the upstream kernel for at least a year
or two.

Theodore Ts'o (2):
  ext4: fold ext4_claim_inode into ext4_new_inode
  ext4: fix race when setting bitmap_uptodate flag

 fs/ext4/balloc.c  |   59 +++++++++----
 fs/ext4/ext4.h    |   11 ++-
 fs/ext4/ialloc.c  |  238 ++++++++++++++++++++++-------------------------------
 fs/ext4/mballoc.c |   79 ++++--------------
 4 files changed, 161 insertions(+), 226 deletions(-)

-- 
1.7.9.107.g8e04a


             reply	other threads:[~2012-02-06 19:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-06 19:54 Theodore Ts'o [this message]
2012-02-06 19:54 ` [PATCH 1/2] ext4: fold ext4_claim_inode into ext4_new_inode Theodore Ts'o
2012-02-06 19:54 ` [PATCH 2/2] ext4: fix race when setting bitmap_uptodate flag Theodore Ts'o

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=1328558084-19430-1-git-send-email-tytso@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    /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).