From: Chris Mason <mason@suse.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [RFC] using writepage to start io
Date: Sat, 28 Jul 2001 12:25:31 -0400 [thread overview]
Message-ID: <86620000.996337531@tiny> (raw)
In-Reply-To: <Pine.GSO.4.21.0107281210460.11772-100000@weyl.math.psu.edu>
On Saturday, July 28, 2001 12:18:02 PM -0400 Alexander Viro <viro@math.psu.edu> wrote:
>
>
> On Sat, 28 Jul 2001, Chris Mason wrote:
>
>>
>> Hello everyone,
>>
>> This is an rfc only, as the code has only been _lightly_ tested. I'll
>> do more tests/benchmarks next week.
>>
>> This patch changes fs/buffer.c to use writepage to start i/o,
>> instead of writing buffers directly. It also changes refile_buffer
>> to mark the page dirty when marking buffers dirty.
>
> ->writepage() unlocks the page upon completion. How do you deal with that?
writepage funcs are added for use by anonymous pages, and
flush_dirty_buffers and friends are changed to expect writepage to unlock
the page on completion.
Also, end_buffer_io_async is changed to only mark the page up to date
when all the buffers on it are up to date. This is important when
blocksize is less than the page size, and block_prepare_write/
block_commit_write are used to dirty a buffer in the middle of a
non-up to date page. If that dirty buffer is written with an
async end_io handler, we don't want the whole page set up to date
by the handler.
-chris
next prev parent reply other threads:[~2001-07-28 16:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-28 16:01 [RFC] using writepage to start io Chris Mason
2001-07-28 16:18 ` Alexander Viro
2001-07-28 16:25 ` Chris Mason [this message]
2001-07-31 19:07 ` Chris Mason
2001-08-01 1:01 ` Daniel Phillips
2001-08-01 2:05 ` Chris Mason
2001-08-01 14:57 ` Daniel Phillips
-- strict thread matches above, loose matches on Subject: below --
2001-08-05 18:34 Chris Mason
2001-08-05 22:38 ` Daniel Phillips
2001-08-05 23:32 ` Chris Mason
2001-08-06 5:39 ` Daniel Phillips
2001-08-06 13:24 ` Chris Mason
2001-08-06 16:13 ` Daniel Phillips
2001-08-06 16:51 ` Chris Mason
2001-08-06 19:45 ` Daniel Phillips
2001-08-06 20:12 ` Chris Mason
2001-08-06 21:18 ` Daniel Phillips
2001-08-07 11:02 ` Stephen C. Tweedie
2001-08-07 11:39 ` Ed Tomlinson
2001-08-07 18:36 ` Daniel Phillips
2001-08-07 12:07 ` Anton Altaparmakov
2001-08-07 12:02 ` Anton Altaparmakov
2001-08-07 13:29 ` Daniel Phillips
2001-08-07 13:31 ` Alexander Viro
2001-08-07 15:52 ` Daniel Phillips
2001-08-07 14:23 ` Stephen C. Tweedie
2001-08-07 15:51 ` Daniel Phillips
2001-08-08 14:49 ` Stephen C. Tweedie
2001-08-06 15:13 ` Eric W. Biederman
2001-08-07 15:19 Chris Mason
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=86620000.996337531@tiny \
--to=mason@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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