From: Vyacheslav Dubeyko <slava@dubeyko.com>
To: Linux FS devel list <linux-fsdevel@vger.kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Hin-Tak Leung <htl10@users.sourceforge.net>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH 00/14] hfsplus: introduce journal replay functionality
Date: Thu, 26 Dec 2013 13:41:31 +0400 [thread overview]
Message-ID: <1388050891.4168.54.camel@slavad-ubuntu> (raw)
Hi,
This patch implements journal replay functionality in HFS+
file system driver.
Technical Note TN1150:
"The purpose of the journal is to ensure that when a group of
related changes are being made, that either all of those changes
are actually made, or none of them are made. This is done by
gathering up all of the changes, and storing them in a separate
place (in the journal). Once the journal copy of the changes is
completely written to disk, the changes can actually be written
to their normal locations on disk. If a failure happens at that
time, the changes can simply be copied from the journal to their
normal locations. If a failure happens when the changes are being
written to the journal, but before they are marked complete, then
all of those changes are ignored."
"A group of related changes is called a transaction. When all of
the changes of a transaction have been written to their normal
locations on disk, that transaction has been committed, and is
removed from the journal. The journal may contain several
transactions. Copying changes from all transactions to their
normal locations on disk is called replaying the journal."
"In order to replay the journal, an implementation just loops
over the transactions, copying each individual block in the
transaction from the journal to its proper location on the
volume. Once those blocks have been flushed to the media
(not just the driver!), it may update the journal header to
remove the transactions."
"Here are the steps to replay the journal:
1. Read the volume header into variable vhb. The volume may
have an HFS wrapper; if so, you will need to use it to
determine the location of the volume header.
2. Test the kHFSVolumeJournaledBit in the attributes field of
the volume header. If it is not set, there is no journal
to replay, and you are done.
3. Read the journal info block from the allocation block number
vhb.journalInfoBlock, into variable jib.
4. If kJIJournalNeedsInitMask is set in jib.flags, the journal
was never initialized, so there is no journal to replay.
5. Verify that kJIJournalInFSMask is set and kJIJournalOnOtherDeviceMask
is clear in jib.flags.
6. Read the journal header at jib.offset bytes from the start
of the volume, and place it in variable jhdr.
7. If jhdr.start equals jhdr.end, the journal does not have
any transactions, so there is nothing to replay.
8. Set the current offset in the journal (typically a local
variable) to the start of the journal buffer, jhdr.start.
9. While jhdr.start does not equal jhdr.end, perform the
following steps:
1. Read a block list header of jhdr.blhdr_size bytes from
the current offset in the journal into variable blhdr.
2. For each block in bhdr.binfo[1] to bhdr.binfo[blhdr.num_blocks],
inclusive, copy bsize bytes from the current offset in
the journal to sector bnum on the volume (to byte offset
bnum*jdhr.jhdr_size). Remember that jhdr_size is the
size of a sector, in bytes.
3. If bhdr.binfo[0].next is zero, you have completed the
last block list of the current transaction; set jhdr.start
to the current offset in the journal."
With the best regards,
Vyacheslav Dubeyko.
---
Documentation/filesystems/hfsplus.txt | 4 +
fs/hfsplus/Makefile | 3 +-
fs/hfsplus/hfsplus_fs.h | 31 +-
fs/hfsplus/hfsplus_raw.h | 53 +-
fs/hfsplus/journal.c | 1207 +++++++++++++++++++++++++++++++++
fs/hfsplus/options.c | 8 +-
fs/hfsplus/part_tbl.c | 4 +-
fs/hfsplus/super.c | 42 +-
fs/hfsplus/wrapper.c | 28 +-
9 files changed, 1356 insertions(+), 24 deletions(-)
--
1.7.9.5
next reply other threads:[~2013-12-26 9:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-26 9:41 Vyacheslav Dubeyko [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-12-26 15:57 [PATCH 00/14] hfsplus: introduce journal replay functionality Hin-Tak Leung
2013-12-27 6:39 ` Vyacheslav Dubeyko
2014-01-19 1:50 Hin-Tak Leung
2014-01-20 7:54 ` Vyacheslav Dubeyko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1388050891.4168.54.camel@slavad-ubuntu \
--to=slava@dubeyko.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=htl10@users.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).