From: Nathan Scott <nscott@aconex.com>
To: David Chinner <dgc@sgi.com>
Cc: xfs-dev@sgi.com, xfs@oss.sgi.com
Subject: Re: Review: Clear unwritten flag on during partial page truncation
Date: Thu, 21 Dec 2006 17:16:58 +1100 [thread overview]
Message-ID: <1166681818.5572.190.camel@edge> (raw)
In-Reply-To: <20061220062813.GU44411608@melbourne.sgi.com>
On Wed, 2006-12-20 at 17:28 +1100, David Chinner wrote:
> Hence the solution is to clear the private buffer flags in
> xfs_vm_invalidatepage() so that when we extend the file the buffers
> on the page are all consistent.
>
> Patch below. Comments?
Looks good Dave, nice sleuthing.
In hindsight, it'd have been really good to have gone for the real
BH_Unwritten flag upfront, and then being able to clear that inside
discard_buffer (like was done for BH_Delay)... if we did that, then
all this new code we're adding here (to just clear_buffer_unwritten,
ultimately) and also the complete hack in xfs_count_page_state could
be removed. It still might be worth considering doing that, in case
there's other hard-to-hit-but-not-yet-uncovered bugs lurking along
the same lines. But alot of effort, with the possibility of it not
being merged at all, as it touches code outside XFS. D'oh.
FWIW, GFS seems to have managed to do even worse here, and looks like
they have dup'd big chunks of buffer.c ... has a discard_buffer() copy
and invalidate_page and probably others which are closely derived from
the equivalent buffer.c code ... guess those guys (hi Russell) could
do some code rationalisation in this area too before they get bitten.
cheers.
--
Nathan
next prev parent reply other threads:[~2006-12-21 6:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-20 6:28 Review: Clear unwritten flag on during partial page truncation David Chinner
2006-12-20 8:21 ` Lachlan McIlroy
2006-12-20 9:07 ` David Chinner
2006-12-21 6:16 ` Nathan Scott [this message]
2006-12-21 11:37 ` David Chinner
2006-12-21 22:04 ` Nathan Scott
2006-12-22 13:21 ` Christoph Hellwig
2006-12-23 2:55 ` 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=1166681818.5572.190.camel@edge \
--to=nscott@aconex.com \
--cc=dgc@sgi.com \
--cc=xfs-dev@sgi.com \
--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