From: Nick Piggin <npiggin@suse.de>
To: David Howells <dhowells@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, mhalcrow@us.ibm.com,
phillip@hellewell.homeip.net, sfrench@samba.org
Subject: Re: [rfc][patch 3/5] afs: new aops
Date: Tue, 13 Nov 2007 01:44:59 +0100 [thread overview]
Message-ID: <20071113004459.GE30650@wotan.suse.de> (raw)
In-Reply-To: <17445.1194913805@redhat.com>
On Tue, Nov 13, 2007 at 12:30:05AM +0000, David Howells wrote:
> Nick Piggin <npiggin@suse.de> wrote:
>
> > PAGE_CACHE_SIZE should be used to address the pagecache.
>
> Perhaps, but the function being called from there takes pages not page cache
> slots. If I have to allow for PAGE_CACHE_SIZE > PAGE_SIZE then I need to
> modify my code, if not then the assertion needs to remain what it is.
It takes a pagecache page, yes. If you follow convention, you use
PAGE_CACHE_SIZE for that guy. You don't have to allow PAGE_CACHE_SIZE !=
PAGE_SIZE, and if all the rest of your code is in units of PAGE_SIZE, then
obviously my changing of just the one unit is even more confusing than
the current arrangement ;)
> > > I notice you removed the stuff that clears holes in the page to be
> > > written. Is this is now done by the caller?
> >
> > It is supposed to bring the page uptodate first. So, no need to clear
> > AFAIKS?
>
> Hmmm... I suppose. However, it is wasteful in the common case as it is then
> bringing the page up to date by filling/clearing the whole of it and not just
> the bits that are not going to be written.
Yes, that's where you come in. You are free (and encouraged) to optimise
this.
Let's see, for a network filesystem this is what you could do:
- if the page is not uptodate at write_begin time, do not bring it uptodate
(at least, not the region that is going to be written to)
- if the page is not uptodate at write_end time, but the copy was fully
completed, just mark it uptodate (provided you brought the regions outside
the copy uptodate).
- if the page is not uptodate and you have a short copy, simply do not
mark the page uptodate or dirty, and return 0 from write_end, indicating
that you have committed 0 bytes. The generic code should DTRT.
Or you could:
Pass back a temporary (not pagecache) page in *pagep, and copy that yourself
into the _real_ pagecache page at write_end time, so you know exactly how
big the copy will be (this is basically what the 2copy method does now...
it is probably not as good as the first method I described, but for a
high latency filesystem it may be preferable to always bringing the page
uptodate).
Or: keep track of sub-page dirty / uptodate status eg. with a light weight
buffer_head like structure, so you can actually have partially dirty pages
that are not completely uptodate.
Or... if you can think of another way...
next prev parent reply other threads:[~2007-11-13 0:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-12 7:12 [rfc][patches] remove ->prepare_write Nick Piggin
2007-11-12 7:13 ` [rfc][patch 1/5] ecryptfs new aops Nick Piggin
2007-11-12 7:14 ` [rfc][patch 2/5] cifs: " Nick Piggin
2007-11-12 7:14 ` [rfc][patch 3/5] afs: " Nick Piggin
2007-11-12 7:20 ` [rfc][patch 4/5] rd: rewrite rd Nick Piggin
2007-11-12 7:23 ` [rfc][patch 5/5] remove prepare_write Nick Piggin
2007-11-12 15:29 ` [rfc][patch 3/5] afs: new aops David Howells
2007-11-13 0:15 ` Nick Piggin
2007-11-13 0:30 ` David Howells
2007-11-13 0:44 ` Nick Piggin [this message]
2007-11-13 10:56 ` David Howells
2007-11-14 4:24 ` Nick Piggin
2007-11-14 12:18 ` David Howells
2007-11-14 15:18 ` Nick Piggin
2007-11-14 15:57 ` David Howells
2007-11-14 21:32 ` Nick Piggin
2007-11-15 12:15 ` David Howells
2007-11-15 21:37 ` Nick Piggin
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=20071113004459.GE30650@wotan.suse.de \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mhalcrow@us.ibm.com \
--cc=phillip@hellewell.homeip.net \
--cc=sfrench@samba.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;
as well as URLs for NNTP newsgroup(s).