From: David Howells <dhowells@redhat.com>
To: David Chinner <dgc@sgi.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2
Date: Wed, 16 May 2007 11:19:29 +0100 [thread overview]
Message-ID: <18993.1179310769@redhat.com> (raw)
In-Reply-To: <20070318233008.GA32597093@melbourne.sgi.com>
David Chinner <dgc@sgi.com> wrote:
> + ret = block_prepare_write(page, 0, end, get_block);
As I understand the way prepare_write() works, this is incorrect.
The start and end points passed to block_prepare_write() delimit the region of
the page that is going to be modified. This means that prepare_write()
doesn't need to fill it in if the page is not up to date. It does, however,
need to fill in the region before (if present) and the region after (if
present). Look at it like this:
+---------------+
| |
| | <-- Filled in by prepare_write()
| |
to-> |:::::::::::::::|
| |
| | <-- Filled in by caller
| |
offset->|:::::::::::::::|
| |
| | <-- Filled in by prepare_write()
| |
page-> +---------------+
However, page_mkwrite() isn't told which bit of the page is going to be
written to. This means it has to ask prepare_write() to make sure the whole
page is filled in. In other words, offset and to must be equal (in AFS I set
them both to 0).
With what you've got, if, say, 'offset' is 0 and 'to' is calculated at
PAGE_SIZE, then if the page is not up to date for any reason, then none of the
page will be updated before the page is written on by the faulting code.
You probably get away with this in a blockdev-based filesystem because it's
unlikely that the page will cease to be up to date.
However, if someone adds a syscall to punch holes in files, this may change...
David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-05-16 10:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-18 23:30 David Chinner
2007-03-19 6:37 ` Nick Piggin
2007-03-19 8:12 ` David Chinner
2007-03-19 9:57 ` Nick Piggin
2007-03-19 10:28 ` Nick Piggin
2007-03-19 9:22 ` Christoph Hellwig
2007-03-19 10:11 ` Nick Piggin
2007-03-19 12:22 ` Christoph Hellwig
2007-03-20 5:34 ` Nick Piggin
2007-05-16 10:19 ` David Howells [this message]
2007-05-16 11:59 ` Nick Piggin
2007-05-16 12:09 ` David Woodhouse
2007-05-16 12:53 ` Chris Mason
2007-05-16 13:04 ` Nick Piggin
2007-05-16 13:10 ` Chris Mason
2007-05-16 13:20 ` David Howells
2007-05-16 13:41 ` Nick Piggin
2007-05-16 13:25 ` David Howells
2007-05-16 23:28 ` David Chinner
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=18993.1179310769@redhat.com \
--to=dhowells@redhat.com \
--cc=dgc@sgi.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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