1. 14 Mar, 2012 1 commit
    • Jan Kara's avatar
      jbd2: remove bh_state lock from checkpointing code · 932bb305
      Jan Kara authored
      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: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: Theodore Ts'o's avatar"Theodore Ts'o" <tytso@mit.edu>
      932bb305
  2. 25 Jul, 2011 1 commit
  3. 21 Mar, 2011 1 commit
    • Amir Goldstein's avatar
      jbd2: add the b_cow_tid field to journal_head struct · c2cc7028
      Amir Goldstein authored
      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: default avatarAmir Goldstein <amir73il@users.sf.net>
      Signed-off-by: Theodore Ts'o's avatar"Theodore Ts'o" <tytso@mit.edu>
      c2cc7028
  4. 05 Jan, 2009 1 commit
    • Joel Becker's avatar
      jbd2: Add buffer triggers · e06c8227
      Joel Becker authored
      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: default avatarJoel Becker <joel.becker@oracle.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      e06c8227
  5. 16 Oct, 2008 1 commit
  6. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!
      1da177e4