1. 24 9月, 2008 1 次提交
  2. 23 9月, 2008 1 次提交
  3. 10 10月, 2008 1 次提交
  4. 09 9月, 2008 1 次提交
  5. 12 7月, 2008 2 次提交
    • J
      ext4: New inode allocation for FLEX_BG meta-data groups. · 772cb7c8
      Jose R. Santos 提交于
      This patch mostly controls the way inode are allocated in order to
      make ialloc aware of flex_bg block group grouping.  It achieves this
      by bypassing the Orlov allocator when block group meta-data are packed
      toghether through mke2fs.  Since the impact on the block allocator is
      minimal, this patch should have little or no effect on other block
      allocation algorithms. By controlling the inode allocation, it can
      basically control where the initial search for new block begins and
      thus indirectly manipulate the block allocator.
      
      This allocator favors data and meta-data locality so the disk will
      gradually be filled from block group zero upward.  This helps improve
      performance by reducing seek time.  Since the group of inode tables
      within one flex_bg are treated as one giant inode table, uninitialized
      block groups would not need to partially initialize as many inode
      table as with Orlov which would help fsck time as the filesystem usage
      goes up.
      Signed-off-by: NJose R. Santos <jrs@us.ibm.com>
      Signed-off-by: NValerie Clement <valerie.clement@bull.net>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      772cb7c8
    • S
      ext4: fix comments to say "ext4" · 8a35694e
      Shen Feng 提交于
      Change second/third to fourth.
      Signed-off-by: NShen Feng <shen@cn.fujitsu.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      8a35694e
  6. 30 4月, 2008 1 次提交
  7. 29 1月, 2008 3 次提交
  8. 18 10月, 2007 1 次提交
  9. 17 10月, 2007 1 次提交
  10. 18 7月, 2007 2 次提交
  11. 17 7月, 2007 1 次提交
  12. 12 10月, 2006 4 次提交
  13. 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