[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E52689F.70606@linux.vnet.ibm.com>
Date: Mon, 22 Aug 2011 07:33:03 -0700
From: Allison Henderson <achender@...ux.vnet.ibm.com>
To: "Ted Ts'o" <tytso@....edu>
CC: linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/6 v5] ext4: Add new ext4_discard_partial_page_buffers
routines
On 08/21/2011 07:38 PM, Ted Ts'o wrote:
> On Sat, Aug 20, 2011 at 07:29:42PM -0700, Allison Henderson wrote:
>> + /* If the range is block aligned, unmap */
>> + if (range_to_discard == blocksize) {
>> + clear_buffer_dirty(bh);
>> + bh->b_bdev = NULL;
>> + clear_buffer_mapped(bh);
>> + clear_buffer_req(bh);
>> + clear_buffer_new(bh);
>> + clear_buffer_delay(bh);
>> + clear_buffer_unwritten(bh);
>> + clear_buffer_uptodate(bh);
>> + ClearPageUptodate(page);
>
> Is this ClearPageUptodate() necessary? If the page is uptodate, and
> we've zero'ed out the relevant space, why do we need to force the page
> to read in from disk again? (In fact, if we want to avoid forcing the
> whole punched region to be written to disk, we'll need to get rid of
> the ClearPageUptodate() sooner or later --- and I'm not sure I see why
> it's needed now. Am I missing something?)
>
> - Ted
Oh, I see, maybe we can take this out now then. Initially we put this
in there when all we were doing was unmapping the buffer heads. The
idea was that if we just unmap the buffer heads and set the page not
uptodate we wouldnt have to zero the page, but since that didnt work out
for the mapped reads, we added the zeroing back in. I'll run some more
tests to see if we can take it out. Thx!
Allison Henderson
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists