From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Chinner <dgc@sgi.com>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@osdl.org
Subject: Re: [PATCH 1/2]: Fix BUG in cancel_dirty_pages on XFS
Date: Thu, 25 Jan 2007 00:43:23 +1100 [thread overview]
Message-ID: <45B7627B.8050202@yahoo.com.au> (raw)
In-Reply-To: <1169640835.6189.14.camel@twins>
Peter Zijlstra wrote:
> On Wed, 2007-01-24 at 09:37 +1100, David Chinner wrote:
>
>>With the recent changes to cancel_dirty_pages(), XFS will
>>dump warnings in the syslog because it can truncate_inode_pages()
>>on dirty mapped pages.
>>
>>I've determined that this is indeed correct behaviour for XFS
>>as this can happen in the case of races on mmap()d files with
>>direct I/O. In this case when we do a direct I/O read, we
>>flush the dirty pages to disk, then truncate them out of the
>>page cache. Unfortunately, between the flush and the truncate
>>the mmap could dirty the page again. At this point we toss a
>>dirty page that is mapped.
>
>
> This sounds iffy, why not just leave the page in the pagecache if its
> mapped anyway?
And why not just leave it in the pagecache and be done with it?
All you need is to do a writeout before a direct IO read, which is
what generic dio code does.
I guess you'll say that direct writes still need to remove pages,
but in that case you'll either have to live with some racyness
(which is what the generic code does), or have a higher level
synchronisation to prevent buffered + direct IO writes I suppose?
>>None of the existing functions for truncating pages or invalidating
>>pages work in this situation. Invalidating a page only works for
>>non-dirty pages with non-dirty buffers, and they only work for
>>whole pages and XFS requires partial page truncation.
>>
>>On top of that the page invalidation functions don't actually
>>call into the filesystem to invalidate the page and so the filesystem
>>can't actually invalidate the page properly (e.g. do stuff based on
>>private buffer head flags).
>
>
> Have you seen the new launder_page() a_op? called from
> invalidate_inode_pages2_range()
It would have been nice to make that one into a more potentially
useful generic callback.
But why was it introduced, exactly? I can't tell from the code or
the discussion why NFS couldn't start the IO, and signal the caller
to wait_on_page_writeback and retry? That seemed to me like the
convetional fix.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2007-01-24 13:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-23 22:37 [PATCH 1/2]: Fix BUG in cancel_dirty_pages on XFS David Chinner
2007-01-24 12:13 ` Peter Zijlstra
2007-01-24 13:43 ` Nick Piggin [this message]
2007-01-24 14:40 ` Peter Zijlstra
2007-01-25 0:05 ` Nick Piggin
2007-01-24 22:46 ` David Chinner
2007-01-25 0:12 ` Nick Piggin
2007-01-25 0:35 ` David Chinner
2007-01-25 0:47 ` Nick Piggin
2007-01-25 1:52 ` David Chinner
2007-01-25 2:01 ` Nick Piggin
2007-01-25 3:42 ` David Chinner
2007-01-25 4:25 ` Nick Piggin
2007-01-25 7:40 ` David Chinner
2007-01-25 10:26 ` Nick Piggin
2007-01-24 22:24 ` 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=45B7627B.8050202@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=dgc@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/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