From: Andreas Dilger <adilger@sun.com>
To: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
Mingming Cao <cmm@us.ibm.com>
Cc: linux-ext4@vger.kernel.org
Subject: ext4_ext_calc_credits_for_single_extent() bug?
Date: Tue, 30 Jun 2009 00:41:33 +0200 [thread overview]
Message-ID: <20090629224133.GF19362@webber.adilger.int> (raw)
I was looking at the function ext4_ext_calc_credits_for_insert(), because
it appeared similar to a function we were using in Lustre and I wanted to
remove redundant code from our patches. On closer inspection, however,
that function is doing something strange that wasn't in our original code.
int ext4_ext_calc_credits_for_single_extent(struct inode *inode, int nrblocks,
struct ext4_ext_path *path)
{
if (path) {
int depth = ext_depth(inode);
int ret = 0;
/* probably there is space in leaf? */
if (le16_to_cpu(path[depth].p_hdr->eh_entries)
< le16_to_cpu(path[depth].p_hdr->eh_max)) {
/*
* There are some space in the leaf tree, no
* need to account for leaf block credit
*
* bitmaps and block group descriptor blocks
* and other metadat blocks still need to be
* accounted.
*/
/* 1 bitmap, 1 block group descriptor */
ret = 2 + EXT4_META_TRANS_BLOCKS(inode->i_sb);
}
}
return ext4_chunk_trans_blocks(inode, nrblocks);
}
It computes "ret" but doesn't actually use it, and then
ext4_chunk_trans_blocks() does nothing but call ext4_meta_trans_blocks(),
which is doing the bulk of the calculation.
It looks like this was committed by Mingming in "ext4: journal credits
reservation fixes for extent file writepage"
ee12b630687d510f6f4b6d4acdc4e267fd4adeda
Ideally we would use the "path" information to generate an accurate block
count for this extent. Can we just return "ret" in this case?
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next reply other threads:[~2009-06-29 22:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 22:41 Andreas Dilger [this message]
2009-07-01 18:38 ` ext4_ext_calc_credits_for_single_extent() bug? Aneesh Kumar K.V
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=20090629224133.GF19362@webber.adilger.int \
--to=adilger@sun.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--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).