typedef_journal_t(9) [centos man page]

TYPEDEF 
JOURNAL_T(9)					     The Linux Journalling API					      TYPEDEF JOURNAL_T(9)

NAME

       typedef_journal_t - The journal_t maintains all of the journaling state information for a single filesystem.

SYNOPSIS

       typedef journal_t;

DESCRIPTION

       journal_t is linked to from the fs superblock structure.

       We use the journal_t to keep track of all outstanding transaction activity on the filesystem, and to manage the state of the log writing
       process.

       This is an opaque datatype.

AUTHORS

       Roger Gammans <rgammans@computer-surgery.co.uk>
	   Author.

       Stephen Tweedie <sct@redhat.com>
	   Author.

COPYRIGHT

Kernel Hackers Manual						     June 2014						      TYPEDEF JOURNAL_T(9)

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)