1. 03 8月, 2008 1 次提交
  2. 27 7月, 2008 2 次提交
  3. 25 7月, 2008 1 次提交
  4. 18 7月, 2008 1 次提交
  5. 02 8月, 2008 1 次提交
  6. 03 8月, 2008 1 次提交
    • T
      ext4: Fix lack of credits BUG() when deleting a badly fragmented inode · bc965ab3
      Theodore Ts'o 提交于
      The extents codepath for ext4_truncate() requests journal transaction
      credits in very small chunks, requesting only what is needed.  This
      means there may not be enough credits left on the transaction handle
      after ext4_truncate() returns and then when ext4_delete_inode() tries
      finish up its work, it may not have enough transaction credits,
      causing a BUG() oops in the jbd2 core.
      
      Also, reserve an extra 2 blocks when starting an ext4_delete_inode()
      since we need to update the inode bitmap, as well as update the
      orphaned inode linked list.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      bc965ab3
  7. 02 8月, 2008 1 次提交
    • T
      ext4: Fix ext4_ext_journal_restart() · 0123c939
      Theodore Ts'o 提交于
      The ext4_ext_journal_restart() is a convenience function which checks
      to see if the requested number of credits is present, and if so it
      closes the current transaction and attaches the current handle to the
      new transaction.  Unfortunately, it wasn't proprely checking the
      return value from ext4_journal_extend(), so it was starting a new
      transaction when one was not necessary, and returning an error when
      all that was necessary was to restart the handle with a new
      transaction.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      0123c939
  8. 03 8月, 2008 1 次提交
  9. 01 8月, 2008 1 次提交
    • H
      jbd2: don't abort if flushing file data failed · e9e34f4e
      Hidehiro Kawai 提交于
      In ordered mode, the current jbd2 aborts the journal if a file data buffer
      has an error.  But this behavior is unintended, and we found that it has
      been adopted accidentally.
      
      This patch undoes it and just calls printk() instead of aborting the
      journal.  Unlike a similar patch for ext3/jbd, file data buffers are
      written via generic_writepages().  But we also need to set AS_EIO
      into their mappings because wait_on_page_writeback_range() clears
      AS_EIO before a user process sees it.
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      e9e34f4e
  10. 27 7月, 2008 1 次提交
    • H
      ext4: don't read inode block if the buffer has a write error · 9c83a923
      Hidehiro Kawai 提交于
      A transient I/O error can corrupt inode data.  Here is the scenario:
      
      (1) update inode_A at the block_B
      (2) pdflush writes out new inode_A to the filesystem, but it results
          in write I/O error, at this point, BH_Uptodate flag of the buffer
          for block_B is cleared and BH_Write_EIO is set
      (3) create new inode_C which located at block_B, and
          __ext4_get_inode_loc() tries to read on-disk block_B because the
          buffer is not uptodate
      (4) if it can read on-disk block_B successfully, inode_A is
          overwritten by old data
      
      This patch makes __ext4_get_inode_loc() not read the inode block if the
      buffer has BH_Write_EIO flag.  In this case, the buffer should have the
      latest information, so setting the uptodate flag to the buffer (this
      avoids WARN_ON_ONCE() in mark_buffer_dirty().)
      
      According to this change, we would need to test BH_Write_EIO flag for the
      error checking.  Currently nobody checks write I/O errors on metadata
      buffers, but it will be done in other patches I'm working on.
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: sugita <yumiko.sugita.yf@hitachi.com>
      Cc: Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      9c83a923
  11. 24 7月, 2008 3 次提交
  12. 03 8月, 2008 2 次提交
    • E
      ext4: lock block groups when initializing · b5f10eed
      Eric Sandeen 提交于
      I noticed when filling a 1T filesystem with 4 threads using the
      fs_mark benchmark:
      
      fs_mark -d /mnt/test -D 256 -n 100000 -t 4 -s 20480 -F -S 0
      
      that I occasionally got checksum mismatch errors:
      
      EXT4-fs error (device sdb): ext4_init_inode_bitmap: Checksum bad for group 6935
      
      etc.  I'd reliably get 4-5 of them during the run.
      
      It appears that the problem is likely a race to init the bg's
      when the uninit_bg feature is enabled.
      
      With the patch below, which adds sb_bgl_locking around initialization,
      I was able to complete several runs with no errors or warnings.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      b5f10eed
    • E
      ext4: sync up block and inode bitmap reading functions · e29d1cde
      Eric Sandeen 提交于
      ext4_read_block_bitmap and read_inode_bitmap do essentially
      the same thing, and yet they are structured quite differently.
      I came across this difference while looking at doing bg locking
      during bg initialization.
      
      This patch:
      
      * removes unnecessary casts in the error messages
      * renames read_inode_bitmap to ext4_read_inode_bitmap
      * and more substantially, restructures the inode bitmap
        reading function to be more like the block bitmap counterpart.
      
      The change to the inode bitmap reader simplifies the locking
      to be applied in the next patch.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      e29d1cde
  13. 27 7月, 2008 1 次提交
  14. 03 8月, 2008 1 次提交
  15. 29 7月, 2008 22 次提交