linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Allison Henderson <achender@linux.vnet.ibm.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/1 v4] ext4: fix xfstests 75, 112, 127 punch hole failure
Date: Thu, 11 Aug 2011 14:31:01 -0700	[thread overview]
Message-ID: <4E444A15.6000405@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110811031712.GF3625@thunk.org>

On 08/10/2011 08:17 PM, Ted Ts'o wrote:
> On Tue, Aug 09, 2011 at 02:10:44PM -0700, Allison Henderson wrote:
>>> 	/*
>>> 	 * Now we need to zero out the non-block-aligned data.
>>> 	 * If the file space being truncated is smaller than
>>> 	 * than a block, just zero out the middle
>>> 	 */
>>>
>> Hmm, for this piece here, Im not sure I quite follow you.  I was
>> pretty sure that ext4_block_zero_page() only deals with ranges that
>> appear with in one block.
>
> Yes, that's true.  What I was objecting to in the comment is the
> phrase "smaller than a block".  That's not right, or it's only right
> if blocksize == page size.  That comment should really read, "if the
> file space is smaller than a ***page***" zero out the middle.
>
> That's what happens in ext4_block_zero_page(), and so it works
> correctly; but the comment is confusing, and it makes the reader think
> that all we only need to zero is based on block boundaries, when in
> fact when we look at zeroing memory, we have to base it on page
> boundaries.
>
> Basically for either punch or truncate what we must do is:
>
>     *) Zero partial pages
>     *) Unmap full pages
>     *) We take buffer_heads which have been freed and either
>        (a) detach them, or
>        (b) clear the mapped flag, to indicate that the block number
>             in the bh is invalid
>
> Using "unmap" for both pages and blocks can be confusing, since for
> pages, unmapping means that we remove the page completely from the
> page cache, so any future attempt to read from that virtual memory
> address will result in a zero page getting mapped in.
>
> However, for buffers, "unmapping" merely means that we are removing
> the mapping to the disk block which has been deallocated by the punch
> operation.  It does not result in anything getting zero'ed out in the
> _page_ cache, which is why we need to zero out partial pages.
>
> Does that make sense?
>
> 						- Ted

Ah, ok then that makes sense.  So maybe what I need to do is modify the 
ext4_block_zero_page routine to zero everything in the specified range 
and then clear the mapped flag for any buffer header that is fully 
zeroed.  I'm not sure I'm clear about what it means to be detached 
though.  What is the difference between clearing the flag and detaching 
the buffer head?  Thank you for all the explaining!

Allison Henderson


  reply	other threads:[~2011-08-11 21:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-07  6:21 [PATCH 1/1 v4] ext4: fix xfstests 75, 112, 127 punch hole failure Allison Henderson
2011-08-08  2:42 ` Ted Ts'o
2011-08-08 20:54   ` Allison Henderson
2011-08-09 16:45     ` Ted Ts'o
2011-08-09 21:10       ` Allison Henderson
2011-08-11  3:17         ` Ted Ts'o
2011-08-11 21:31           ` Allison Henderson [this message]
2011-08-11 23:44             ` Ted 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=4E444A15.6000405@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 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).