An error occurred fetching the project authors.
  1. 04 Jan, 2012 1 commit
    • Yongqiang Yang's avatar
      ext4: add new online resize interface · 19c5246d
      Yongqiang Yang authored
      This patch adds new online resize interface, whose input argument is a
      64-bit integer indicating how many blocks there are in the resized fs.
      
      In new resize impelmentation, all work like allocating group tables
      are done by kernel side, so the new resize interface can support
      flex_bg feature and prepares ground for suppoting resize with features
      like bigalloc and exclude bitmap. Besides these, user-space tools just
      passes in the new number of blocks.
      
      We delay initializing the bitmaps and inode tables of added groups if
      possible and add multi groups (a flex groups) each time, so new resize
      is very fast like mkfs.
      Signed-off-by: default avatarYongqiang Yang <xiaoqiangnk@gmail.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      19c5246d
  2. 08 Oct, 2011 2 commits
  3. 03 Sep, 2011 1 commit
    • Theodore Ts'o's avatar
      ext4: improve handling of conflicting mount options · 56889787
      Theodore Ts'o authored
      If the user explicitly specifies conflicting mount options for
      delalloc or dioread_nolock and data=journal, fail the mount, instead
      of printing a warning and continuing (since many user's won't look at
      dmesg and notice the warning).
      
      Also, print a single warning that data=journal implies that delayed
      allocation is not on by default (since it's not supported), and
      furthermore that O_DIRECT is not supported.  Improve the text in
      Documentation/filesystems/ext4.txt so this is clear there as well.
      
      Similarly, if the dioread_nolock mount option is specified when the
      file system block size != PAGE_SIZE, fail the mount instead of
      printing a warning message and ignoring the mount option.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      56889787
  4. 25 Jun, 2011 1 commit
  5. 01 May, 2011 1 commit
  6. 31 Mar, 2011 1 commit
  7. 22 Feb, 2011 1 commit
  8. 28 Oct, 2010 1 commit
    • Lukas Czerner's avatar
      ext4: add support for lazy inode table initialization · bfff6873
      Lukas Czerner authored
      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: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      bfff6873
  9. 24 Dec, 2009 1 commit
  10. 19 Nov, 2009 2 commits
  11. 02 Nov, 2009 1 commit
    • Linus Torvalds's avatar
      Revert "ext4: Remove journal_checksum mount option and enable it by default" · d4da6c9c
      Linus Torvalds authored
      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: default avatarEric 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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d4da6c9c
  12. 29 Sep, 2009 1 commit
  13. 18 Sep, 2009 1 commit
  14. 05 Sep, 2009 1 commit
  15. 13 Jun, 2009 1 commit
  16. 12 Jun, 2009 1 commit
  17. 28 Mar, 2009 1 commit
    • Theodore Ts'o's avatar
      ext4: Regularize mount options · 06705bff
      Theodore Ts'o authored
      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: default avatar"Theodore Ts'o" <tytso@mit.edu>
      06705bff
  18. 23 Feb, 2009 1 commit
  19. 06 Jan, 2009 3 commits
  20. 04 Jan, 2009 1 commit
  21. 06 Jan, 2009 1 commit
  22. 17 Oct, 2008 1 commit
  23. 11 Oct, 2008 2 commits
    • Hidehiro Kawai's avatar
      ext4: add an option to control error handling on file data · 5bf5683a
      Hidehiro Kawai authored
      If the journal doesn't abort when it gets an IO error in file data
      blocks, the file data corruption will spread silently.  Because
      most of applications and commands do buffered writes without fsync(),
      they don't notice the IO error.  It's scary for mission critical
      systems.  On the other hand, if the journal aborts whenever it gets
      an IO error in file data blocks, the system will easily become
      inoperable.  So this patch introduces a filesystem option to
      determine whether it aborts the journal or just call printk() when
      it gets an IO error in file data.
      
      If you mount an ext4 fs with data_err=abort option, it aborts on file
      data write error.  If you mount it with data_err=ignore, it doesn't
      abort, just call printk().  data_err=ignore is the default.
      
      Here is the corresponding patch of the ext3 version:
      http://kerneltrap.org/mailarchive/linux-kernel/2008/9/9/3239374Signed-off-by: default avatarHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      5bf5683a
    • Theodore Ts'o's avatar
      ext4: Rename ext4dev to ext4 · 03010a33
      Theodore Ts'o authored
      The ext4 filesystem is getting stable enough that it's time to drop
      the "dev" prefix.  Also remove the requirement for the TEST_FILESYS
      flag.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      03010a33
  24. 10 Oct, 2008 1 commit
    • Theodore Ts'o's avatar
      ext4: Use readahead when reading an inode from the inode table · 240799cd
      Theodore Ts'o authored
      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: default avatar"Theodore Ts'o" <tytso@mit.edu>
      240799cd
  25. 27 Jul, 2008 1 commit
  26. 11 Jul, 2008 2 commits
  27. 26 May, 2008 1 commit
    • Eric Sandeen's avatar
      ext4: enable barriers by default · 571640ca
      Eric Sandeen authored
      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: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      571640ca
  28. 29 Jan, 2008 2 commits
  29. 11 Oct, 2006 1 commit
  30. 26 Jun, 2006 1 commit
  31. 12 Jan, 2006 1 commit
  32. 10 Jan, 2006 1 commit
  33. 09 Jan, 2006 1 commit