All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allison Henderson <achender@linux.vnet.ibm.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 1/1 v3] ext4: fix xfstests 75, 112, 127 punch hole failure
Date: Thu, 04 Aug 2011 09:10:12 -0700	[thread overview]
Message-ID: <4E3AC464.30709@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110804152519.GJ3150@thunk.org>

On 08/04/2011 08:25 AM, Ted Ts'o wrote:
> On Thu, Aug 04, 2011 at 12:22:58AM -0700, Allison Henderson wrote:
>>
>> Oh, I think we do avoid calling the unmap for this last condition
>> though.  The first and last page offsets are calculated earlier for
>> calling truncate_inode_pages_range to release all the pages in the
>> hole. The idea is that everything from first_page_offset to
>> last_page_offset covers all the page aligned pages in the hole.  So
>> then if offset and length are aligned, we basically end up with
>> first_page_offset = offset and last_page_offset = offset + length,
>> and the page_len will turn out to be zero.  Right math?  Maybe we
>> can add some comments or something to help clarify.
>
> Yeah, sorry, I wasn't clear enough about the condition.  Consider the
> situation where we punch the region:
>
>     4092 -- 8197
>
> In the previous section of code, we would zero out the byte ranges
> 4092--4095 and 8192--8197.  What's left is a completely page-aligned
> range, which would have already been taken care of already.  But since
> we're calculating based on offsets, I believe there will be an
> unnecessary call to ext4_unmap_page_range().

Oh I see, that makes sense now :)  I will add in something to check for 
that condition.

>
> BTW, the name ext4_unmap_page_range() is a bit confusing; maybe we
> should rename it to ext4_unmap_partial_page_buffers()?
>
> I know you were copying from the ext4_block_zero_page_range() function
> and its calling sequence (but in my opinion that function wasn't named
> well and the comments in that code aren't good either).
>
> I also wonder why we can't fold the functionality found in
> ext4_unmap_page_range() into ext4_block_zero_page_range().  Did you
> look into that option?

Yes, an earlier version of this patch looked a lot like that. (It was 
reviewed on an internal list before it came to the ext4 list, but I keep 
the version numbers so that people on both lists dont get confused).  I 
guess it's just a question of whether people would prefer one complex 
function or two simple functions. I will send v2 to the ext4 list so 
that people can get an idea of what the complex version looks like.

I do think ext4_unmap_partial_page_buffers is probably a more 
descriptive name though. If we choose to keep it as a separate function, 
I will add that in.

Allison Henderson

>
> Regards,
>
> 						- Ted


  reply	other threads:[~2011-08-04 16:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-03 15:20 [PATCH 1/1 v3] ext4: fix xfstests 75, 112, 127 punch hole failure Allison Henderson
2011-08-04  0:50 ` Ted Ts'o
2011-08-04  6:21   ` Allison Henderson
2011-08-04  7:22   ` Allison Henderson
2011-08-04 15:25     ` Ted Ts'o
2011-08-04 16:10       ` Allison Henderson [this message]
2011-08-04 17:44       ` Mingming Cao
2011-08-04 18:03         ` Allison Henderson

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=4E3AC464.30709@linux.vnet.ibm.com \
    --to=achender@linux.vnet.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.