1. 28 10月, 2010 1 次提交
    • L
      ext4: add support for lazy inode table initialization · bfff6873
      Lukas Czerner 提交于
      When the lazy_itable_init extended option is passed to mke2fs, it
      considerably speeds up filesystem creation because inode tables are
      not zeroed out.  The fact that parts of the inode table are
      uninitialized is not a problem so long as the block group descriptors,
      which contain information regarding how much of the inode table has
      been initialized, has not been corrupted However, if the block group
      checksums are not valid, e2fsck must scan the entire inode table, and
      the the old, uninitialized data could potentially cause e2fsck to
      report false problems.
      
      Hence, it is important for the inode tables to be initialized as soon
      as possble.  This commit adds this feature so that mke2fs can safely
      use the lazy inode table initialization feature to speed up formatting
      file systems.
      
      This is done via a new new kernel thread called ext4lazyinit, which is
      created on demand and destroyed, when it is no longer needed.  There
      is only one thread for all ext4 filesystems in the system. When the
      first filesystem with inititable mount option is mounted, ext4lazyinit
      thread is created, then the filesystem can register its request in the
      request list.
      
      This thread then walks through the list of requests picking up
      scheduled requests and invoking ext4_init_inode_table(). Next schedule
      time for the request is computed by multiplying the time it took to
      zero out last inode table with wait multiplier, which can be set with
      the (init_itable=n) mount option (default is 10).  We are doing
      this so we do not take the whole I/O bandwidth. When the thread is no
      longer necessary (request list is empty) it frees the appropriate
      structures and exits (and can be created later later by another
      filesystem).
      
      We do not disturb regular inode allocations in any way, it just do not
      care whether the inode table is, or is not zeroed. But when zeroing, we
      have to skip used inodes, obviously. Also we should prevent new inode
      allocations from the group, while zeroing is on the way. For that we
      take write alloc_sem lock in ext4_init_inode_table() and read alloc_sem
      in the ext4_claim_inode, so when we are unlucky and allocator hits the
      group which is currently being zeroed, it just has to wait.
      
      This can be suppresed using the mount option no_init_itable.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      bfff6873
  2. 25 12月, 2009 1 次提交
  3. 20 11月, 2009 2 次提交
  4. 03 11月, 2009 1 次提交
    • L
      Revert "ext4: Remove journal_checksum mount option and enable it by default" · d4da6c9c
      Linus Torvalds 提交于
      This reverts commit d0646f7b, as
      requested by Eric Sandeen.
      
      It can basically cause an ext4 filesystem to miss recovery (and thus get
      mounted with errors) if the journal checksum does not match.
      
      Quoth Eric:
      
         "My hand-wavy hunch about what is happening is that we're finding a
          bad checksum on the last partially-written transaction, which is
          not surprising, but if we have a wrapped log and we're doing the
          initial scan for head/tail, and we abort scanning on that bad
          checksum, then we are essentially running an unrecovered filesystem.
      
          But that's hand-wavy and I need to go look at the code.
      
          We lived without journal checksums on by default until now, and at
          this point they're doing more harm than good, so we should revert
          the default-changing commit until we can fix it and do some good
          power-fail testing with the fixes in place."
      
      See
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=14354
      
      for all the gory details.
      Requested-by: NEric Sandeen <sandeen@redhat.com>
      Cc: Theodore Tso <tytso@mit.edu>
      Cc: Alexey Fisher <bug-track@fisher-privat.net>
      Cc: Maxim Levitsky <maximlevitsky@gmail.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Mathias Burén <mathias.buren@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d4da6c9c
  5. 30 9月, 2009 1 次提交
  6. 19 9月, 2009 1 次提交
  7. 06 9月, 2009 1 次提交
  8. 13 6月, 2009 2 次提交
  9. 28 3月, 2009 1 次提交
    • T
      ext4: Regularize mount options · 06705bff
      Theodore Ts'o 提交于
      Add support for using the mount options "barrier" and "nobarrier", and
      "auto_da_alloc" and "noauto_da_alloc", which is more consistent than
      "barrier=<0|1>" or "auto_da_alloc=<0|1>".  Most other ext3/ext4 mount
      options use the foo/nofoo naming convention.  We allow the old forms
      of these mount options for backwards compatibility.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      06705bff
  10. 23 2月, 2009 1 次提交
  11. 07 1月, 2009 1 次提交
    • T
      ext4: Remove "extents" mount option · 83982b6f
      Theodore Ts'o 提交于
      This mount option is largely superfluous, and in fact the way it was
      implemented was buggy; if a filesystem which did not have the extents
      feature flag was mounted -o extents, the filesystem would attempt to
      create and use extents-based file even though the extents feature flag
      was not eabled.  The simplest thing to do is to nuke the mount option
      entirely.  It's not all that useful to force the non-creation of new
      extent-based files if the filesystem can support it.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      83982b6f
  12. 06 1月, 2009 1 次提交
  13. 07 1月, 2009 1 次提交
  14. 04 1月, 2009 1 次提交
  15. 07 1月, 2009 1 次提交
  16. 17 10月, 2008 1 次提交
  17. 11 10月, 2008 2 次提交
  18. 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
  19. 28 7月, 2008 1 次提交
  20. 12 7月, 2008 2 次提交
  21. 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
  22. 29 1月, 2008 2 次提交
  23. 12 10月, 2006 1 次提交
  24. 27 6月, 2006 1 次提交
  25. 12 1月, 2006 1 次提交
  26. 11 1月, 2006 1 次提交
  27. 09 1月, 2006 1 次提交
  28. 13 12月, 2005 1 次提交
  29. 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