From: Mingming Cao <cmm@us.ibm.com>
To: Alex Tomas <alex@clusterfs.com>
Cc: "Amit K. Arora" <aarora@linux.vnet.ibm.com>,
linux-ext4@vger.kernel.org, suparna@in.ibm.com
Subject: Re: [PATCH 1/1 version2] Extent overlap bugfix in ext4
Date: Thu, 04 Jan 2007 11:47:36 -0800 [thread overview]
Message-ID: <459D59D8.5040308@us.ibm.com> (raw)
In-Reply-To: <m3irfmehra.fsf@bzzz.home.net>
Alex Tomas wrote:
>>>>>>Amit K Arora (AKA) writes:
>
>
> AKA> @@ -1984,6 +2034,10 @@ int ext4_ext_get_blocks(handle_t *handle
> AKA> */
> AKA> if (ee_len > EXT_MAX_LEN)
> AKA> goto out2;
> AKA> +
> AKA> + if (iblock < ee_block && iblock + max_blocks >= ee_block)
> AKA> + allocated = ee_block - iblock;
> AKA> +
> AKA> /* if found extent covers block, simply return it */
> AKA> if (iblock >= ee_block && iblock < ee_block + ee_len) {
> AKA> newblock = iblock - ee_block + ee_start;
>
> I thought existing code already does this:
>
> /* if found extent covers block, simply return it */
> if (iblock >= ee_block && iblock < ee_block + ee_len) {
> newblock = iblock - ee_block + ee_start;
> /* number of remaining blocks in the extent */
> allocated = ee_len - (iblock - ee_block);
>
>
> thanks, Alex
That's different: the existing code address the case when the left part
of the new extent overlaps with an exisitng extent, in that case I
understand it just returns the allocated part of extent, and continue
the block allocation in the next call of get_blocks().
Well Amit's new code here trying to address the case when the right part
of the new extent overlap with an exisitng extent. He was trying to
update the new extent length to prevent that. As I mentioned ealier we
could put this code into ext4_ext_check_overlap,let it judge whether
there is overlap, and if so, what's the right start block number and length
Thanks,
Mingming
next prev parent reply other threads:[~2007-01-04 19:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-02 9:09 [PATCH 1/1] Extent overlap bugfix in ext4 Amit K. Arora
2007-01-02 9:25 ` Alex Tomas
2007-01-02 9:47 ` Amit K. Arora
2007-01-03 9:44 ` Alex Tomas
2007-01-03 18:07 ` Mingming Cao
2007-01-04 8:13 ` Amit K. Arora
2007-01-04 10:04 ` Alex Tomas
2007-01-04 18:23 ` Mingming Cao
2007-01-03 1:35 ` Mingming Cao
2007-01-03 6:06 ` Amit K. Arora
2007-01-04 8:54 ` [PATCH 1/1 version2] " Amit K. Arora
2007-01-04 10:25 ` Alex Tomas
2007-01-04 11:16 ` Amit K. Arora
2007-01-04 10:39 ` Alex Tomas
2007-01-04 11:27 ` Amit K. Arora
2007-01-04 11:37 ` Alex Tomas
2007-01-04 17:23 ` Amit K. Arora
2007-01-04 18:50 ` Mingming Cao
2007-01-04 19:19 ` Alex Tomas
2007-01-05 12:13 ` Amit K. Arora
2007-01-09 5:51 ` [PATCH 1/1 version3] " Amit K. Arora
2007-01-04 19:03 ` [PATCH 1/1 version2] " Alex Tomas
2007-01-04 19:47 ` Mingming Cao [this message]
2007-01-05 6:18 ` Amit K. Arora
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=459D59D8.5040308@us.ibm.com \
--to=cmm@us.ibm.com \
--cc=aarora@linux.vnet.ibm.com \
--cc=alex@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=suparna@in.ibm.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).