On Wed, 2007-05-30 at 11:35 +0100, David Howells wrote:
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > All I do is to protect new calls to read() and write() with a call to
> > check if the page cache needs invalidating.
>
> What about mmap()? What if someone gets a mapping on a section of
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> All I do is to protect new calls to read() and write() with a call to
> check if the page cache needs invalidating.
What about mmap()? What if someone gets a mapping on a section of file that
subsequently has a write rejected on it? If you
Trond Myklebust [EMAIL PROTECTED] wrote:
All I do is to protect new calls to read() and write() with a call to
check if the page cache needs invalidating.
What about mmap()? What if someone gets a mapping on a section of file that
subsequently has a write rejected on it? If you invalidate
On Wed, 2007-05-30 at 11:35 +0100, David Howells wrote:
Trond Myklebust [EMAIL PROTECTED] wrote:
All I do is to protect new calls to read() and write() with a call to
check if the page cache needs invalidating.
What about mmap()? What if someone gets a mapping on a section of file that
On Fri, 2007-05-25 at 00:18 +0100, David Howells wrote:
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > No. If the write fails, then NFS will mark the mapping as invalid and
> > attempt to call invalidate_inode_pages2() at the earliest possible
> > moment.
>
> Will it erase *all* unwritten
Andrew Morton <[EMAIL PROTECTED]> wrote:
> But we already covered that? Your exciser can do an unconditional
> end_page_writeback(), because it is this thread of control which did the
> set_page_writeback(). So we end up with:
Ah, I misunderstood what you meant. I assumed you meant to wait
On Fri, 25 May 2007 00:08:43 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > hm. I don't see why that race window would be a problem in practice: the
> > page-exciser does a lock_page();wait_on_page_writeback() as normal, then
> > proceeds with
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> No. If the write fails, then NFS will mark the mapping as invalid and
> attempt to call invalidate_inode_pages2() at the earliest possible
> moment.
Will it erase *all* unwritten writes? Or is that what launder_page() is for?
How do you deal with
Andrew Morton <[EMAIL PROTECTED]> wrote:
> hm. I don't see why that race window would be a problem in practice: the
> page-exciser does a lock_page();wait_on_page_writeback() as normal, then
> proceeds with its business?
No. The page-exciser ends (cancels) PG_writeback, not waits for it
On Thu, 24 May 2007 23:34:33 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > So my reason for asking the above is to try to find a way to make all these
> > new PG-error games just go away.
>
> Yeah. However, there needs to be something to cover
On Thu, 2007-05-24 at 22:35 +0100, David Howells wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Could you please flesh this out a bit, from a higher level?
>
> See the description for patch 3/4.
>
> > As in: what does it mean for a server to "reject" a write? What's actually
> > going
Andrew Morton <[EMAIL PROTECTED]> wrote:
> So my reason for asking the above is to try to find a way to make all these
> new PG-error games just go away.
Yeah. However, there needs to be something to cover the gap between releasing
PG_writeback and getting PG_lock. They have to be done in that
On Thu, 24 May 2007 22:35:22 +0100
David Howells <[EMAIL PROTECTED]> wrote:
>
> > Why can't we just run the end_page_writeback() unconditionally?
> > PG_writeback _must_ be set here, and it is the caller who set PG_writeback,
> > so this thread of control "owns" that flag.
>
> You may be
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Could you please flesh this out a bit, from a higher level?
See the description for patch 3/4.
> As in: what does it mean for a server to "reject" a write? What's actually
> going on here?
Simply, it means that the server refused to perform the write.
On Wed, 23 May 2007 20:15:24 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> Add a function - cancel_rejected_write() - to excise a rejected write from the
> pagecache. This function is related to the truncation family of routines. It
> permits the pages modified by a network filesystem client
On Wed, 23 May 2007 20:15:24 +0100
David Howells [EMAIL PROTECTED] wrote:
Add a function - cancel_rejected_write() - to excise a rejected write from the
pagecache. This function is related to the truncation family of routines. It
permits the pages modified by a network filesystem client
Andrew Morton [EMAIL PROTECTED] wrote:
Could you please flesh this out a bit, from a higher level?
See the description for patch 3/4.
As in: what does it mean for a server to reject a write? What's actually
going on here?
Simply, it means that the server refused to perform the write. The
On Thu, 24 May 2007 22:35:22 +0100
David Howells [EMAIL PROTECTED] wrote:
Why can't we just run the end_page_writeback() unconditionally?
PG_writeback _must_ be set here, and it is the caller who set PG_writeback,
so this thread of control owns that flag.
You may be right. I'm trying
Andrew Morton [EMAIL PROTECTED] wrote:
So my reason for asking the above is to try to find a way to make all these
new PG-error games just go away.
Yeah. However, there needs to be something to cover the gap between releasing
PG_writeback and getting PG_lock. They have to be done in that
On Thu, 2007-05-24 at 22:35 +0100, David Howells wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
Could you please flesh this out a bit, from a higher level?
See the description for patch 3/4.
As in: what does it mean for a server to reject a write? What's actually
going on here?
On Thu, 24 May 2007 23:34:33 +0100
David Howells [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
So my reason for asking the above is to try to find a way to make all these
new PG-error games just go away.
Yeah. However, there needs to be something to cover the gap
Andrew Morton [EMAIL PROTECTED] wrote:
hm. I don't see why that race window would be a problem in practice: the
page-exciser does a lock_page();wait_on_page_writeback() as normal, then
proceeds with its business?
No. The page-exciser ends (cancels) PG_writeback, not waits for it (something
Trond Myklebust [EMAIL PROTECTED] wrote:
No. If the write fails, then NFS will mark the mapping as invalid and
attempt to call invalidate_inode_pages2() at the earliest possible
moment.
Will it erase *all* unwritten writes? Or is that what launder_page() is for?
How do you deal with pages
On Fri, 25 May 2007 00:08:43 +0100
David Howells [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
hm. I don't see why that race window would be a problem in practice: the
page-exciser does a lock_page();wait_on_page_writeback() as normal, then
proceeds with its business?
Andrew Morton [EMAIL PROTECTED] wrote:
But we already covered that? Your exciser can do an unconditional
end_page_writeback(), because it is this thread of control which did the
set_page_writeback(). So we end up with:
Ah, I misunderstood what you meant. I assumed you meant to wait insted
On Fri, 2007-05-25 at 00:18 +0100, David Howells wrote:
Trond Myklebust [EMAIL PROTECTED] wrote:
No. If the write fails, then NFS will mark the mapping as invalid and
attempt to call invalidate_inode_pages2() at the earliest possible
moment.
Will it erase *all* unwritten writes? Or is
Add a function - cancel_rejected_write() - to excise a rejected write from the
pagecache. This function is related to the truncation family of routines. It
permits the pages modified by a network filesystem client (such as AFS) to be
excised and discarded from the pagecache if the attempt to
Add a function - cancel_rejected_write() - to excise a rejected write from the
pagecache. This function is related to the truncation family of routines. It
permits the pages modified by a network filesystem client (such as AFS) to be
excised and discarded from the pagecache if the attempt to
28 matches
Mail list logo
