From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Josef Bacik <josef@redhat.com>
Cc: Jan Kara <jack@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
npiggin@suse.de, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize
Date: Thu, 28 May 2009 18:40:00 +0530 [thread overview]
Message-ID: <20090528131000.GA7398@skywalker> (raw)
In-Reply-To: <20090528130341.GC14315@dhcp231-156.rdu.redhat.com>
On Thu, May 28, 2009 at 09:03:41AM -0400, Josef Bacik wrote:
> On Wed, May 27, 2009 at 03:01:00PM +0200, Jan Kara wrote:
> >
>
> Sorry, another possibly braindead question. When we extend the i_size you make
> it so that the page will be faulted the next time it's written to via
> page_mkclean, which from what I can tell is done via pte_wrprotect. The problem
> with this is the next time we write to the page, we do pte_mkwrite, which makes
> it so that we won't fault the next time we write, correct? So if I were to do
>
> ftruncate(fd, 0);
> pwrite(fd, buf, 1024, 0);
> map = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0);
> map[0] = 'a';
> ftruncate(fd, 10000);
> map[0] = 'b'; --> causes a page fault again
This will do block allocation for the entire page within i_size. (ie multiple blocks)
ext4_page_mkwrite have
size = i_size_read(..)
if (page->index == size >> PAGE_CACHE_SHIFT)
len = size & ~PAGE_CACHE_MASK;
else
len = PAGE_CACHE_SIZE;
> memset(map, 'a', 4096); --> wouldn't cause a pagefault
> writepage at some point
>
> We'd still be in the position that you are trying to solve, correct, since we
> will have dirtied the rest of the page without calling mkwrite for the other
> sections of it, which would result in unallocated blocks when we hit writepage.
> Thanks,
>
-aneesh
next prev parent reply other threads:[~2009-05-28 13:10 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-27 13:00 [PATCH 0/11] Fix page_mkwrite() for blocksize < pagesize Jan Kara
2009-05-27 13:00 ` [PATCH 01/11] ext3: Get rid of extenddisksize parameter of ext3_get_blocks_handle() Jan Kara
2009-05-27 13:00 ` [PATCH 02/11] ext4: Get rid of extend_disksize parameter of ext4_get_blocks_handle() Jan Kara
2009-05-27 13:01 ` [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize Jan Kara
2009-05-27 16:00 ` Josef Bacik
2009-05-27 16:45 ` Aneesh Kumar K.V
2009-05-27 17:06 ` Josef Bacik
2009-05-28 13:03 ` Josef Bacik
2009-05-28 13:10 ` Aneesh Kumar K.V [this message]
2009-05-30 11:23 ` Pavel Machek
2009-06-01 9:44 ` Jan Kara
2009-06-01 11:33 ` Goswin von Brederlow
2009-06-01 14:00 ` Jan Kara
2009-06-01 14:46 ` Goswin von Brederlow
2009-06-01 15:02 ` Jan Kara
2009-06-01 15:35 ` Goswin von Brederlow
2009-05-27 13:01 ` [PATCH 04/11] ext2: Allocate space for mmaped file on page fault Jan Kara
2009-05-27 13:01 ` [PATCH 05/11] ext4: Make sure blocks are properly allocated under mmaped page even when blocksize < pagesize Jan Kara
2009-05-27 14:30 ` Theodore Tso
2009-05-27 14:52 ` Jan Kara
2009-06-04 14:09 ` Theodore Tso
2009-05-27 13:01 ` [PATCH 06/11] ext3: Allocate space for mmaped file on page fault Jan Kara
2009-05-27 13:01 ` [PATCH 07/11] vfs: Implement generic per-cpu counters for delayed allocation Jan Kara
2009-05-27 13:01 ` [PATCH 08/11] vfs: Unmap underlying metadata of new data buffers only when buffer is mapped Jan Kara
2009-05-27 15:35 ` Aneesh Kumar K.V
2009-05-28 9:44 ` Jan Kara
2009-05-28 10:15 ` Aneesh Kumar K.V
2009-05-28 13:50 ` Jan Kara
2009-05-27 13:01 ` [PATCH 09/11] fs: Don't clear dirty bits in block_write_full_page() Jan Kara
2009-05-27 13:01 ` [PATCH 10/11] vfs: Export wakeup_pdflush Jan Kara
2009-05-27 13:01 ` [PATCH 11/11] ext3: Implement delayed allocation on page_mkwrite time Jan Kara
2009-05-27 14:23 ` [PATCH 0/11] Fix page_mkwrite() for blocksize < pagesize Theodore Tso
2009-05-27 14:59 ` Jan Kara
2009-06-04 17:11 ` Theodore Tso
2009-06-05 23:23 ` Jan Kara
2009-05-27 15:33 ` Aneesh Kumar K.V
2009-05-28 9:36 ` Jan Kara
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=20090528131000.GA7398@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=jack@suse.cz \
--cc=josef@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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.