1. 06 1月, 2009 1 次提交
  2. 07 1月, 2009 1 次提交
  3. 04 1月, 2009 1 次提交
  4. 07 1月, 2009 1 次提交
  5. 17 10月, 2008 1 次提交
  6. 11 10月, 2008 2 次提交
  7. 10 10月, 2008 1 次提交
    • T
      ext4: Use readahead when reading an inode from the inode table · 240799cd
      Theodore Ts'o 提交于
      With modern hard drives, reading 64k takes roughly the same time as
      reading a 4k block.  So request readahead for adjacent inode table
      blocks to reduce the time it takes when iterating over directories
      (especially when doing this in htree sort order) in a cold cache case.
      With this patch, the time it takes to run "git status" on a kernel
      tree after flushing the caches via "echo 3 > /proc/sys/vm/drop_caches"
      is reduced by 21%.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      240799cd
  8. 28 7月, 2008 1 次提交
  9. 12 7月, 2008 2 次提交
  10. 27 5月, 2008 1 次提交
    • E
      ext4: enable barriers by default · 571640ca
      Eric Sandeen 提交于
      I can't think of any valid reason for ext4 to not use barriers when
      they are available;  I believe this is necessary for filesystem
      integrity in the face of a volatile write cache on storage.
      
      An administrator who trusts that the cache is sufficiently battery-
      backed (and power supplies are sufficiently redundant, etc...)
      can always turn it back off again.
      
      SuSE has carried such a patch for ext3 for quite some time now.
      
      Also document the mount option while we're at it.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      571640ca
  11. 29 1月, 2008 2 次提交
  12. 12 10月, 2006 1 次提交
  13. 27 6月, 2006 1 次提交
  14. 12 1月, 2006 1 次提交
  15. 11 1月, 2006 1 次提交
  16. 09 1月, 2006 1 次提交
  17. 13 12月, 2005 1 次提交
  18. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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