Visit Our UNIX and Linux User Community

Linux and UNIX Man Pages

Test Your Knowledge in Computers #365
Difficulty: Medium
The original code for vi was written by Bill Joy in 1976.
True or False?
Linux & Unix Commands - Search Man Pages

journal_try_to_free_buffers(9) [centos man page]

JOURNAL_TRY_TO_FREE_(9) 				     The Linux Journalling API					   JOURNAL_TRY_TO_FREE_(9)

NAME
journal_try_to_free_buffers - try to free page buffers. SYNOPSIS
int journal_try_to_free_buffers(journal_t * journal, struct page * page, gfp_t gfp_mask); ARGUMENTS
journal journal for operation page to try and free gfp_mask we use the mask to detect how hard should we try to release buffers. If __GFP_WAIT and __GFP_FS is set, we wait for commit code to release the buffers. DESCRIPTION
For all the buffers on this page, if they are fully written out ordered data, move them onto BUF_CLEAN so try_to_free_buffers can reap them. This function returns non-zero if we wish try_to_free_buffers to be called. We do this if the page is releasable by try_to_free_buffers. We also do it if the page has locked or dirty buffers and the caller wants us to perform sync or async writeout. 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. This may *change* the value of transaction_t->t_datalist, so anyone who looks at t_datalist needs to lock against this function. Even worse, someone may be doing a journal_dirty_data on this buffer. So we need to lock against that. journal_dirty_data will come out of the lock with the buffer dirty, which makes it ineligible for release here. Who else is affected by this? hmm... Really the only contender is do_get_write_access - it could be looking at the buffer while journal_try_to_free_buffer 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? Return 0 on failure, 1 on success AUTHORS
Roger Gammans <rgammans@computer-surgery.co.uk> Author. Stephen Tweedie <sct@redhat.com> Author. COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 JOURNAL_TRY_TO_FREE_(9)

Check Out this Related Man Page

JOURNAL_ABORT(9)					     The Linux Journalling API						  JOURNAL_ABORT(9)

NAME
journal_abort - Shutdown the journal immediately. SYNOPSIS
void journal_abort(journal_t * journal, int errno); ARGUMENTS
journal the journal to shutdown. errno an error number to record in the journal indicating the reason for the shutdown. DESCRIPTION
Perform a complete, immediate shutdown of the ENTIRE journal (not of a single transaction). This operation cannot be undone without closing and reopening the journal. The journal_abort function is intended to support higher level error recovery mechanisms such as the ext2/ext3 remount-readonly error mode. Journal abort has very specific semantics. Any existing dirty, unjournaled buffers in the main filesystem will still be written to disk by bdflush, but the journaling mechanism will be suspended immediately and no further transaction commits will be honoured. Any dirty, journaled buffers will be written back to disk without hitting the journal. Atomicity cannot be guaranteed on an aborted filesystem, but we _do_ attempt to leave as much data as possible behind for fsck to use for cleanup. Any attempt to get a new transaction handle on a journal which is in ABORT state will just result in an -EROFS error return. A journal_stop on an existing handle will return -EIO if we have entered abort state during the update. Recursive transactions are not disturbed by journal abort until the final journal_stop, which will receive the -EIO error. Finally, the journal_abort call allows the caller to supply an errno which will be recorded (if possible) in the journal superblock. This allows a client to record failure conditions in the middle of a transaction without having to complete the transaction to record the failure to disk. ext3_error, for example, now uses this functionality. Errors which originate from within the journaling layer will NOT supply an errno; a null errno implies that absolutely no further writes are done to the journal (unless there are any already in progress). AUTHORS
Roger Gammans <rgammans@computer-surgery.co.uk> Author. Stephen Tweedie <sct@redhat.com> Author. COPYRIGHT
Kernel Hackers Manual 2.6. July 2010 JOURNAL_ABORT(9)

Featured Tech Videos