1JOURNAL_ABORT(9) The Linux Journalling API JOURNAL_ABORT(9)
2
3
4
6 journal_abort - Shutdown the journal immediately.
7
9 void journal_abort(journal_t * journal, int errno);
10
12 journal
13 the journal to shutdown.
14
15 errno
16 an error number to record in the journal indicating the reason for
17 the shutdown.
18
20 Perform a complete, immediate shutdown of the ENTIRE journal (not of a
21 single transaction). This operation cannot be undone without closing
22 and reopening the journal.
23
24 The journal_abort function is intended to support higher level error
25 recovery mechanisms such as the ext2/ext3 remount-readonly error mode.
26
27 Journal abort has very specific semantics. Any existing dirty,
28 unjournaled buffers in the main filesystem will still be written to
29 disk by bdflush, but the journaling mechanism will be suspended
30 immediately and no further transaction commits will be honoured.
31
32 Any dirty, journaled buffers will be written back to disk without
33 hitting the journal. Atomicity cannot be guaranteed on an aborted
34 filesystem, but we _do_ attempt to leave as much data as possible
35 behind for fsck to use for cleanup.
36
37 Any attempt to get a new transaction handle on a journal which is in
38 ABORT state will just result in an -EROFS error return. A journal_stop
39 on an existing handle will return -EIO if we have entered abort state
40 during the update.
41
42 Recursive transactions are not disturbed by journal abort until the
43 final journal_stop, which will receive the -EIO error.
44
45 Finally, the journal_abort call allows the caller to supply an errno
46 which will be recorded (if possible) in the journal superblock. This
47 allows a client to record failure conditions in the middle of a
48 transaction without having to complete the transaction to record the
49 failure to disk. ext3_error, for example, now uses this functionality.
50
51 Errors which originate from within the journaling layer will NOT supply
52 an errno; a null errno implies that absolutely no further writes are
53 done to the journal (unless there are any already in progress).
54
56 Roger Gammans <rgammans@computer-surgery.co.uk>
57 Author.
58
59 Stephen Tweedie <sct@redhat.com>
60 Author.
61
63Kernel Hackers Manual 2.6. June 2019 JOURNAL_ABORT(9)