From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: cmm@us.ibm.com, sandeen@redhat.com, frederic.bohe@bull.net,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH 6/6] ext4: don't use the block freed but not yet committed during buddy initialization
Date: Sun, 2 Nov 2008 21:43:40 -0500 [thread overview]
Message-ID: <20081103024340.GT8134@mit.edu> (raw)
In-Reply-To: <1225471859-19718-6-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Fri, Oct 31, 2008 at 10:20:59PM +0530, Aneesh Kumar K.V wrote:
> When we generate buddy cache(especially during resize) we need to make
> sure we don't use the blocks freed but not yet comitted. This make
> sure we have the right value of free blocks count in the group
> info and also in the bitmap. This also ensures the ordered mode
> consistency
Wouldn't this be fixed if we have resize call ext4_mb_free_blocks()
instead of having it regeneerate the buddy cache?
- Ted
next prev parent reply other threads:[~2008-11-03 2:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-31 16:50 [PATCH 1/6] ext4: Add blocks added during resize to bitmap Aneesh Kumar K.V
2008-10-31 16:50 ` [PATCH 2/6] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize Aneesh Kumar K.V
2008-10-31 16:50 ` [PATCH 3/6] ext4: cleanup mballoc header files Aneesh Kumar K.V
2008-10-31 16:50 ` [PATCH 4/6] ext4: sparse annotate the group info semaphore Aneesh Kumar K.V
2008-10-31 16:50 ` [PATCH 5/6] ext4: Call journal commit callback without holding j_list_lock Aneesh Kumar K.V
2008-10-31 16:50 ` [PATCH 6/6] ext4: don't use the block freed but not yet committed during buddy initialization Aneesh Kumar K.V
2008-11-03 2:43 ` Theodore Tso [this message]
2008-11-03 2:42 ` [PATCH 5/6] ext4: Call journal commit callback without holding j_list_lock Theodore Tso
2008-11-03 2:33 ` [PATCH 1/6] ext4: Add blocks added during resize to bitmap Theodore Tso
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=20081103024340.GT8134@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=frederic.bohe@bull.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.