1. 09 Dec, 2009 3 commits
  2. 07 Dec, 2009 2 commits
  3. 01 Dec, 2009 1 commit
  4. 24 Nov, 2009 5 commits
  5. 23 Nov, 2009 4 commits
  6. 22 Nov, 2009 1 commit
  7. 23 Nov, 2009 1 commit
  8. 24 Nov, 2009 1 commit
  9. 23 Nov, 2009 1 commit
    • Theodore Ts'o's avatar
      ext4: move ext4_forget() to ext4_jbd2.c · d6797d14
      Theodore Ts'o authored
      The ext4_forget() function better belongs in ext4_jbd2.c.  This will
      allow us to do some cleanup of the ext4_journal_revoke() and
      ext4_journal_forget() functions, as well as giving us better error
      reporting since we can report the caller of ext4_forget() when things
      go wrong.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      d6797d14
  10. 19 Nov, 2009 2 commits
  11. 23 Nov, 2009 2 commits
  12. 15 Nov, 2009 1 commit
  13. 23 Nov, 2009 2 commits
  14. 15 Nov, 2009 2 commits
  15. 23 Nov, 2009 3 commits
    • Theodore Ts'o's avatar
      ext4: make sure directory and symlink blocks are revoked · 50689696
      Theodore Ts'o authored
      When an inode gets unlinked, the functions ext4_clear_blocks() and
      ext4_remove_blocks() call ext4_forget() for all the buffer heads
      corresponding to the deleted inode's data blocks.  If the inode is a
      directory or a symlink, the is_metadata parameter must be non-zero so
      ext4_forget() will revoke them via jbd2_journal_revoke().  Otherwise,
      if these blocks are reused for a data file, and the system crashes
      before a journal checkpoint, the journal replay could end up
      corrupting these data blocks.
      
      Thanks to Curt Wohlgemuth for pointing out potential problems in this
      area.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      50689696
    • Theodore Ts'o's avatar
      ext4: add tracepoint for ext4_forget() · beac2da7
      Theodore Ts'o authored
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      beac2da7
    • Theodore Ts'o's avatar
      ext4: remove failed journal checksum check · cf40db13
      Theodore Ts'o authored
      Now that we are checking for failed journal checksums in the jbd2
      layer, we don't need to check in the ext4 mount path --- since a
      checksum fail will result in ext4_load_journal() returning an error,
      causing the file system to refuse to be mounted until e2fsck can deal
      with the problem.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      cf40db13
  16. 15 Nov, 2009 1 commit
    • Theodore Ts'o's avatar
      jbd2: don't wipe the journal on a failed journal checksum · e6a47428
      Theodore Ts'o authored
      If there is a failed journal checksum, don't reset the journal.  This
      allows for userspace programs to decide how to recover from this
      situation.  It may be that ignoring the journal checksum failure might
      be a better way of recovering the file system.  Once we add per-block
      checksums, we can definitely do better.  Until then, a system
      administrator can try backing up the file system image (or taking a
      snapshot) and and trying to determine experimentally whether ignoring
      the checksum failure or aborting the journal replay results in less
      data loss.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      e6a47428
  17. 14 Nov, 2009 1 commit
  18. 23 Nov, 2009 6 commits
  19. 13 Nov, 2009 1 commit