.\" 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 "JOURNAL_TRY_TO_FREE_BUFFERS" "" "06 October 2005" "" ""

.SH NAME
journal_try_to_free_buffers \- try to free page buffers.
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
int journal_try_to_free_buffers  (journal_t * \fIjournal\fB, struct page * \fIpage\fB, int \fIunused_gfp_mask\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIjournal\fB\fR
journal for operation
.TP
\fB\fIpage\fB\fR
to try and free
.TP
\fB\fIunused_gfp_mask\fB\fR
-- undescribed --
.SH "DESCRIPTION"
.PP
.PP
For all the buffers on this page,
if they are fully written out ordered data, move them onto BUF_CLEAN
so \fBtry_to_free_buffers\fR can reap them.
.PP
This function returns non-zero if we wish \fBtry_to_free_buffers\fR
to be called. We do this if the page is releasable by \fBtry_to_free_buffers\fR\&.
We also do it if the page has locked or dirty buffers and the caller wants
us to perform sync or async writeout.
.PP
This complicates JBD locking somewhat.  We aren't protected by the
BKL here.  We wish to remove the buffer from its committing or
running transaction's ->t_datalist via __journal_unfile_buffer.
.PP
This may *change* the value of transaction_t->t_datalist, so anyone
who looks at t_datalist needs to lock against this function.
.PP
Even worse, someone may be doing a journal_dirty_data on this
buffer.  So we need to lock against that.  \fBjournal_dirty_data\fR
will come out of the lock with the buffer dirty, which makes it
ineligible for release here.
.PP
Who else is affected by this?  hmm...  Really the only contender
is \fBdo_get_write_access\fR - it could be looking at the buffer while
\fBjournal_try_to_free_buffer\fR is changing its state.  But that
cannot happen because we never reallocate freed data as metadata
while the data is part of a transaction.  Yes?