.\" This manpage has been automatically generated by docbook2man 
.\" from a DocBook document.  This tool can be found at:
.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
.\" Please send any bug reports, improvements, comments, patches, 
.\" etc. to Steve Cheng <steve@ggi-project.org>.
.TH "MPAGE_WRITEPAGES" "" "06 October 2005" "" ""

.SH NAME
mpage_writepages \- walk the list of dirty pages of the given
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
int mpage_writepages  (struct address_space * \fImapping\fB, struct writeback_control * \fIwbc\fB, get_block_t \fIget_block\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fImapping\fB\fR
address space structure to write
.TP
\fB\fIwbc\fB\fR
subtract the number of written pages from *\fIwbc\fR->nr_to_write
.TP
\fB\fIget_block\fB\fR
the filesystem's block mapper function.
If this is NULL then use a_ops->writepage.  Otherwise, go
direct-to-BIO.
.SH "DESCRIPTION"
.PP
This is a library function, which implements the \fBwritepages\fR
address_space_operation.
.PP
(The next two paragraphs refer to code which isn't here yet, but they
explain the presence of address_space.io_pages)
.PP
Pages can be moved from clean_pages or locked_pages onto dirty_pages
at any time - it's not possible to lock against that.  So pages which
have already been added to a BIO may magically reappear on the dirty_pages
list.  And \fBmpage_writepages\fR will again try to lock those pages.
But I/O has not yet been started against the page.  Thus deadlock.
.PP
To avoid this, \fBmpage_writepages\fR will only write pages from io_pages. The
caller must place them there.  We walk io_pages, locking the pages and
submitting them for I/O, moving them to locked_pages.
.PP
This has the added benefit of preventing a livelock which would otherwise
occur if pages are being dirtied faster than we can write them out.
.PP
If a page is already under I/O, \fBgeneric_writepages\fR skips it, even
if it's dirty.  This is desirable behaviour for memory-cleaning writeback,
but it is INCORRECT for data-integrity system calls such as \fBfsync\fR\&.  \fBfsync\fR
and \fBmsync\fR need to guarantee that all the data which was dirty at the time
the call was made get new I/O started against them.  So if \fBcalled_for_sync\fR
is true, we must wait for existing IO to complete.
.PP
It's fairly rare for PageWriteback pages to be on ->dirty_pages.  It
means that someone redirtied the page while it was under I/O.
.SH "DESCRIPTION"
.PP
This is a library function, which implements the \fBwritepages\fR
address_space_operation.
.PP
(The next two paragraphs refer to code which isn't here yet, but they
explain the presence of address_space.io_pages)
.PP
Pages can be moved from clean_pages or locked_pages onto dirty_pages
at any time - it's not possible to lock against that.  So pages which
have already been added to a BIO may magically reappear on the dirty_pages
list.  And \fBmpage_writepages\fR will again try to lock those pages.
But I/O has not yet been started against the page.  Thus deadlock.
.PP
To avoid this, \fBmpage_writepages\fR will only write pages from io_pages. The
caller must place them there.  We walk io_pages, locking the pages and
submitting them for I/O, moving them to locked_pages.
.PP
This has the added benefit of preventing a livelock which would otherwise
occur if pages are being dirtied faster than we can write them out.
.PP
If a page is already under I/O, \fBgeneric_writepages\fR skips it, even
if it's dirty.  This is desirable behaviour for memory-cleaning writeback,
but it is INCORRECT for data-integrity system calls such as \fBfsync\fR\&.  \fBfsync\fR
and \fBmsync\fR need to guarantee that all the data which was dirty at the time
the call was made get new I/O started against them.  So if \fBcalled_for_sync\fR
is true, we must wait for existing IO to complete.
.PP
It's fairly rare for PageWriteback pages to be on ->dirty_pages.  It
means that someone redirtied the page while it was under I/O.