summaryrefslogtreecommitdiff
path: root/include/linux/journal-head.h
AgeCommit message (Collapse)AuthorFilesLines
2012-03-13jbd2: remove bh_state lock from checkpointing codeJan Kara1-0/+2
All accesses to checkpointing entries in journal_head are protected by j_list_lock. Thus __jbd2_journal_remove_checkpoint() doesn't really need bh_state lock. Also the only part of journal head that the rest of checkpointing code needs to check is jh->b_transaction which is safe to read under j_list_lock. So we can safely remove bh_state lock from all of checkpointing code which makes it considerably prettier. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2011-07-25jbd: change the field "b_cow_tid" of struct journal_head from type unsigned ↵Wang Sheng-Hui1-1/+1
to tid_t In the definition of struct journal_head, the comment for the field "unsigned b_cow_tid" says the field tracks the last transaction id in which this buffer has been cowed. In the header part of file journal-head.h, it defines typedef unsigned int tid_t; We should use type tid_t to define transaction id fields. Change the field "b_cow_tid" of struct journal_head from type unsigned to tid_t. Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> Acked-by: Amir Goldstein <amir73il@users.sf.net> Signed-off-by: Jan Kara <jack@suse.cz>
2011-03-20jbd2: add the b_cow_tid field to journal_head structAmir Goldstein1-0/+7
The b_cow_tid field will be used by the ext4 snapshots code to store the transaction id when the buffer was last cowed. Merging this patch to mainline will allow users to test ext4 snapshots as a standalone module, without the need to patch and install a development kernel. On 64bit machines this field uses fills in a padding "hole" and does not increase the size of the struct. On a 32bit machine this patch increases the size of the struct from 60 to 64 bytes. Signed-off-by: Amir Goldstein <amir73il@users.sf.net> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-01-05jbd2: Add buffer triggersJoel Becker1-0/+8
Filesystems often to do compute intensive operation on some metadata. If this operation is repeated many times, it can be very expensive. It would be much nicer if the operation could be performed once before a buffer goes to disk. This adds triggers to jbd2 buffer heads. Just before writing a metadata buffer to the journal, jbd2 will optionally call a commit trigger associated with the buffer. If the journal is aborted, an abort trigger will be called on any dirty buffers as they are dropped from pending transactions. ocfs2 will use this feature. Initially I tried to come up with a more generic trigger that could be used for non-buffer-related events like transaction completion. It doesn't tie nicely, because the information a buffer trigger needs (specific to a journal_head) isn't the same as what a transaction trigger needs (specific to a tranaction_t or perhaps journal_t). So I implemented a buffer set, with the understanding that journal/transaction wide triggers should be implemented separately. There is only one trigger set allowed per buffer. I can't think of any reason to attach more than one set. Contrast this with a journal or transaction in which multiple places may want to watch the entire transaction separately. The trigger sets are considered static allocation from the jbd2 perspective. ocfs2 will just have one trigger set per block type, setting the same set on every bh of the same type. Signed-off-by: Joel Becker <joel.becker@oracle.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: <linux-ext4@vger.kernel.org> Signed-off-by: Mark Fasheh <mfasheh@suse.com>
2008-10-16Remove Andrew Morton's old email accountsFrancois Cami1-1/+1
People can use the real name an an index into MAINTAINERS to find the current email address. Signed-off-by: Francois Cami <francois.cami@free.fr> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+92
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!