From: David Chinner <dgc@sgi.com>
To: Nathan Scott <nscott@aconex.com>
Cc: David Chinner <dgc@sgi.com>, Timothy Shimmin <tes@sgi.com>,
xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: Review: ensure EOF writes into existing extents update filesize
Date: Tue, 22 May 2007 16:05:59 +1000 [thread overview]
Message-ID: <20070522060559.GI86004887@sgi.com> (raw)
In-Reply-To: <1179807014.6273.519.camel@edge>
On Tue, May 22, 2007 at 02:10:14PM +1000, Nathan Scott wrote:
> On Tue, 2007-05-22 at 11:03 +1000, David Chinner wrote:
> > On Tue, May 22, 2007 at 11:02:59AM +1000, Nathan Scott wrote:
> > > On Tue, 2007-05-22 at 10:44 +1000, David Chinner wrote:
> > > > On Mon, May 21, 2007 at 04:34:26PM +1000, Timothy Shimmin wrote:
> > > > I guess I need to ping Christoph and Nathan on this one....
> > >
> > > Could you resend the patch to me please? I lost the previous copy
> > > while ruthlessly ploughing through my mail backlog. ;)
> >
> > Below.
>
> Looks pretty good to me - xfs_convert_page has been overlooked, I
> think - attached patch fixes that.
I thought about that, then tried to trip the problem and was not
successful. AFAICT, if we have multiple pages dirty and in the same
state (i.e. pwrite 0 32769 to dirty 3 pages, then sync, then pwrite
0 33000 to dirty and extend) we should hit the case where we cluster
the dirty pages and call xfs_convert_page() on the last two pages.
In that case, the entire range should be mapped via the one iomap
and so the last buffer (the one we extended) should be added to an
ioend with a type of 0 (IOMAP_READ) and hence we should see the bug.
With the patch I posted, I can't get this to show the problem. It
should, but it doesn't....
I'll make the change anyway to be safe, but I'm still perplexed
as to why it doesn't seem necessary....
Ah - there it is - xfs_is_delayed_page():
699 if (buffer_unwritten(bh))
700 acceptable = (type == IOMAP_UNWRITTEN);
701 else if (buffer_delay(bh))
702 acceptable = (type == IOMAP_DELAY);
703 else if (buffer_dirty(bh) && buffer_mapped(bh))
704 >>>>>>>>>>> acceptable = (type == 0);
705 else
706 break;
The ioend we started with now has type = IOMAP_NEW = 0x40 which
means xfs_convert_page() aborts clustering this case immediately.
IOWs, we are never getting to this xfs_convert_page() case and
we are only passing through xfs_page_state_convert for mapped
pages.
> You also initialise iomap_valid
> twice inside xfs_page_state_convert now ... I reverted that to just
> the once.
I'll fold these changes in and fixup xfs_is_delayed_page() to look
for type == IOMAP_NEW and send out a new patch. Thanks, Nathan.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2007-05-22 6:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-20 23:34 Review: ensure EOF writes into existing extents update filesize David Chinner
2007-05-20 23:40 ` Chris Wedgwood
2007-05-20 23:44 ` David Chinner
2007-05-21 6:34 ` Timothy Shimmin
2007-05-22 0:44 ` David Chinner
2007-05-22 1:02 ` Nathan Scott
2007-05-22 1:03 ` David Chinner
2007-05-22 4:10 ` Nathan Scott
2007-05-22 6:05 ` David Chinner [this message]
2007-05-23 0:02 ` David Chinner
2007-05-23 0:15 ` Nathan Scott
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=20070522060559.GI86004887@sgi.com \
--to=dgc@sgi.com \
--cc=nscott@aconex.com \
--cc=tes@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