1JOURNAL_TRY_TO_FREE_(9)    The Linux Journalling API   JOURNAL_TRY_TO_FREE_(9)
2
3
4

NAME

6       journal_try_to_free_buffers - try to free page buffers.
7

SYNOPSIS

9       int journal_try_to_free_buffers(journal_t * journal,
10                                       struct page * page, gfp_t gfp_mask);
11

ARGUMENTS

13       journal
14           journal for operation
15
16       page
17           to try and free
18
19       gfp_mask
20           we use the mask to detect how hard should we try to release
21           buffers. If __GFP_WAIT and __GFP_FS is set, we wait for commit code
22           to release the buffers.
23

DESCRIPTION

25       For all the buffers on this page, if they are fully written out ordered
26       data, move them onto BUF_CLEAN so try_to_free_buffers can reap them.
27
28       This function returns non-zero if we wish try_to_free_buffers to be
29       called. We do this if the page is releasable by try_to_free_buffers. We
30       also do it if the page has locked or dirty buffers and the caller wants
31       us to perform sync or async writeout.
32
33       This complicates JBD locking somewhat. We aren't protected by the BKL
34       here. We wish to remove the buffer from its committing or running
35       transaction's ->t_datalist via __journal_unfile_buffer.
36
37       This may *change* the value of transaction_t->t_datalist, so anyone who
38       looks at t_datalist needs to lock against this function.
39
40       Even worse, someone may be doing a journal_dirty_data on this buffer.
41       So we need to lock against that.  journal_dirty_data will come out of
42       the lock with the buffer dirty, which makes it ineligible for release
43       here.
44
45       Who else is affected by this? hmm... Really the only contender is
46       do_get_write_access - it could be looking at the buffer while
47       journal_try_to_free_buffer is changing its state. But that cannot
48       happen because we never reallocate freed data as metadata while the
49       data is part of a transaction. Yes?
50
51       Return 0 on failure, 1 on success
52

AUTHORS

54       Roger Gammans <rgammans@computer-surgery.co.uk>
55           Author.
56
57       Stephen Tweedie <sct@redhat.com>
58           Author.
59

61Kernel Hackers Manual 2.6.       November 2011         JOURNAL_TRY_TO_FREE_(9)
Impressum