1. 26 4月, 2009 1 次提交
  2. 05 3月, 2009 1 次提交
  3. 27 1月, 2009 1 次提交
  4. 06 1月, 2009 6 次提交
  5. 07 1月, 2009 1 次提交
    • F
      ext4: Allow ext4 to run without a journal · 0390131b
      Frank Mayhar 提交于
      A few weeks ago I posted a patch for discussion that allowed ext4 to run
      without a journal.  Since that time I've integrated the excellent
      comments from Andreas and fixed several serious bugs.  We're currently
      running with this patch and generating some performance numbers against
      both ext2 (with backported reservations code) and ext4 with and without
      a journal.  It just so happens that running without a journal is
      slightly faster for most everything.
      
      We did
      	iozone -T -t 4 s 2g -r 256k -T -I -i0 -i1 -i2
      
      which creates 4 threads, each of which create and do reads and writes on
      a 2G file, with a buffer size of 256K, using O_DIRECT for all file opens
      to bypass the page cache.  Results:
      
                           ext2        ext4, default   ext4, no journal
        initial writes   13.0 MB/s        15.4 MB/s          15.7 MB/s
        rewrites         13.1 MB/s        15.6 MB/s          15.9 MB/s
        reads            15.2 MB/s        16.9 MB/s          17.2 MB/s
        re-reads         15.3 MB/s        16.9 MB/s          17.2 MB/s
        random readers    5.6 MB/s         5.6 MB/s           5.7 MB/s
        random writers    5.1 MB/s         5.3 MB/s           5.4 MB/s 
      
      So it seems that, so far, this was a useful exercise.
      Signed-off-by: NFrank Mayhar <fmayhar@google.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      0390131b
  6. 27 11月, 2008 1 次提交
  7. 10 10月, 2008 1 次提交
  8. 08 9月, 2008 1 次提交
  9. 09 9月, 2008 1 次提交
  10. 20 8月, 2008 1 次提交
  11. 27 7月, 2008 1 次提交
  12. 12 7月, 2008 1 次提交
  13. 20 6月, 2008 1 次提交
  14. 07 6月, 2008 1 次提交
  15. 30 4月, 2008 2 次提交
  16. 17 4月, 2008 2 次提交
  17. 26 2月, 2008 1 次提交
  18. 08 2月, 2008 1 次提交
  19. 29 1月, 2008 2 次提交
  20. 18 10月, 2007 3 次提交
    • E
      ext4: lighten up resize transaction requirements · 14904107
      Eric Sandeen 提交于
      When resizing online, setup_new_group_blocks attempts to reserve a
      potentially very large transaction, depending on the current filesystem
      geometry.  For some journal sizes, there may not be enough room for this
      transaction, and the online resize will fail.
      
      The patch below resizes & restarts the transaction as necessary while
      setting up the new group, and should work with even the smallest journal.
      
      Tested with something like:
      
      [root@newbox ~]# dd if=/dev/zero of=fsfile bs=1024 count=32768
      [root@newbox ~]# mkfs.ext3 -b 1024 fsfile 16384
      [root@newbox ~]# mount -o loop fsfile mnt/
      [root@newbox ~]# resize2fs /dev/loop0
      resize2fs 1.40.2 (12-Jul-2007)
      Filesystem at /dev/loop0 is mounted on /root/mnt; on-line resizing required
      old desc_blocks = 1, new_desc_blocks = 1
      Performing an on-line resize of /dev/loop0 to 32768 (1k) blocks.
      resize2fs: No space left on device While trying to add group #2
      [root@newbox ~]# dmesg | tail -n 1
      JBD: resize2fs wants too many credits (258 > 256)
      [root@newbox ~]#
      
      With the below change, it works.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Acked-by: NAndreas Dilger <adilger@clusterfs.com>
      14904107
    • E
      ext4: fix setup_new_group_blocks locking · 5b615287
      Eric Sandeen 提交于
      setup_new_group_blocks() manipulates the group descriptor block bh
      under the block_bitmap bh's lock.  It shouldn't matter since nobody
      but resize should be touching these blocks, but it's worth fixing up.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      5b615287
    • A
      Ext4: Uninitialized Block Groups · 717d50e4
      Andreas Dilger 提交于
      In pass1 of e2fsck, every inode table in the fileystem is scanned and checked,
      regardless of whether it is in use.  This is this the most time consuming part
      of the filesystem check.  The unintialized block group feature can greatly
      reduce e2fsck time by eliminating checking of uninitialized inodes.
      
      With this feature, there is a a high water mark of used inodes for each block
      group.  Block and inode bitmaps can be uninitialized on disk via a flag in the
      group descriptor to avoid reading or scanning them at e2fsck time.  A checksum
      of each group descriptor is used to ensure that corruption in the group
      descriptor's bit flags does not cause incorrect operation.
      
      The feature is enabled through a mkfs option
      
      	mke2fs /dev/ -O uninit_groups
      
      A patch adding support for uninitialized block groups to e2fsprogs tools has
      been posted to the linux-ext4 mailing list.
      
      The patches have been stress tested with fsstress and fsx.  In performance
      tests testing e2fsck time, we have seen that e2fsck time on ext3 grows
      linearly with the total number of inodes in the filesytem.  In ext4 with the
      uninitialized block groups feature, the e2fsck time is constant, based
      solely on the number of used inodes rather than the total inode count.
      Since typical ext4 filesystems only use 1-10% of their inodes, this feature can
      greatly reduce e2fsck time for users.  With performance improvement of 2-20
      times, depending on how full the filesystem is.
      
      The attached graph shows the major improvements in e2fsck times in filesystems
      with a large total inode count, but few inodes in use.
      
      In each group descriptor if we have
      
      EXT4_BG_INODE_UNINIT set in bg_flags:
              Inode table is not initialized/used in this group. So we can skip
              the consistency check during fsck.
      EXT4_BG_BLOCK_UNINIT set in bg_flags:
              No block in the group is used. So we can skip the block bitmap
              verification for this group.
      
      We also add two new fields to group descriptor as a part of
      uninitialized group patch.
      
              __le16  bg_itable_unused;       /* Unused inodes count */
              __le16  bg_checksum;            /* crc16(sb_uuid+group+desc) */
      
      bg_itable_unused:
      
      If we have EXT4_BG_INODE_UNINIT not set in bg_flags
      then bg_itable_unused will give the offset within
      the inode table till the inodes are used. This can be
      used by fsck to skip list of inodes that are marked unused.
      
      bg_checksum:
      Now that we depend on bg_flags and bg_itable_unused to determine
      the block and inode usage, we need to make sure group descriptor
      is not corrupt. We add checksum to group descriptor to
      detect corruption. If the descriptor is found to be corrupt, we
      mark all the blocks and inodes in the group used.
      Signed-off-by: NAvantika Mathur <mathur@us.ibm.com>
      Signed-off-by: NAndreas Dilger <adilger@clusterfs.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      717d50e4
  21. 17 10月, 2007 1 次提交
  22. 09 5月, 2007 1 次提交
  23. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  24. 29 10月, 2006 1 次提交
    • R
      [PATCH] ext4: fix printk format warnings · 1939e49a
      Randy Dunlap 提交于
      fs/ext4/resize.c:72: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:76: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:81: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:85: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 5)
      fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 5)
      fs/ext4/resize.c:98: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:103: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:109: warning: long long unsigned int format, __u64 arg (arg 4)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1939e49a
  25. 12 10月, 2006 6 次提交