1. 29 5月, 2012 1 次提交
  2. 27 5月, 2012 2 次提交
  3. 21 5月, 2012 1 次提交
    • T
      ext4: enable the 64-bit jbd2 feature based on the 64-bit ext4 feature · f32aaf2d
      Theodore Ts'o 提交于
      Previously we were only enabling the 64-bit jbd2 feature if the number
      of blocks in the file system was greater 2**32-1.  The problem with
      this is that it makes it harder to test the 64-bit journal code paths
      with small file systems, since a small test file system would with the
      64-bit ext4 feature enable would use a 64-bit file system on-disk data
      structures, but use a 32-bit journal.
      
      This would also cause problems when trying to do an online resize to
      grow the filesystem above the 2**32-1 boundary.  Fortunately the patch
      to support online resize for 64-bit file systems hasn't been merged
      yet, so this problem hasn't arisen in practice.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      f32aaf2d
  4. 30 4月, 2012 15 次提交
  5. 24 4月, 2012 1 次提交
  6. 17 4月, 2012 2 次提交
  7. 13 4月, 2012 1 次提交
  8. 30 3月, 2012 1 次提交
    • L
      Revert "ext4: don't release page refs in ext4_end_bio()" · 6268b325
      Linus Torvalds 提交于
      This reverts commit b43d17f3.
      
      Dave Jones reports that it causes lockups on his laptop, and his debug
      output showed a lot of processes hung waiting for page_writeback (or
      more commonly - processes hung waiting for a lock that was held during
      that writeback wait).
      
      The page_writeback hint made Ted suggest that Dave look at this commit,
      and Dave verified that reverting it makes his problems go away.
      
      Ted says:
       "That commit fixes a race which is seen when you write into fallocated
        (and hence uninitialized) disk blocks under *very* heavy memory
        pressure.  Furthermore, although theoretically it could trigger under
        normal direct I/O writes, it only seems to trigger if you are issuing
        a huge number of AIO writes, such that a just-written page can get
        evicted from memory, and then read back into memory, before the
        workqueue has a chance to update the extent tree.
      
        This race has been around for a little over a year, and no one noticed
        until two months ago; it only happens under fairly exotic conditions,
        and in fact even after trying very hard to create a simple repro under
        lab conditions, we could only reproduce the problem and confirm the
        fix on production servers running MySQL on very fast PCIe-attached
        flash devices.
      
        Given that Dave was able to hit this problem pretty quickly, if we
        confirm that this commit is at fault, the only reasonable thing to do
        is to revert it IMO."
      Reported-and-tested-by: NDave Jones <davej@redhat.com>
      Acked-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6268b325
  9. 22 3月, 2012 8 次提交
  10. 21 3月, 2012 3 次提交
  11. 20 3月, 2012 5 次提交