1. 05 8月, 2010 1 次提交
    • E
      ext4: re-inline ext4_rec_len_(to|from)_disk functions · 0cfc9255
      Eric Sandeen 提交于
      commit 3d0518f4, "ext4: New rec_len encoding for very
      large blocksizes" made several changes to this path, but from
      a perf perspective, un-inlining ext4_rec_len_from_disk() seems
      most significant.  This function is called from ext4_check_dir_entry(),
      which on a file-creation workload is called extremely often.
      
      I tested this with bonnie:
      
      # bonnie++ -u root -s 0 -f -x 200 -d /mnt/test -n 32
      
      (this does 200 iterations) and got this for the file creations:
      
      ext4 stock:   Average =  21206.8 files/s
      ext4 inlined: Average =  22346.7 files/s  (+5%)
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      0cfc9255
  2. 02 8月, 2010 1 次提交
  3. 27 7月, 2010 7 次提交
  4. 30 6月, 2010 1 次提交
  5. 29 6月, 2010 2 次提交
  6. 15 6月, 2010 1 次提交
  7. 12 6月, 2010 1 次提交
    • T
      ext4: Clean up s_dirt handling · a0375156
      Theodore Ts'o 提交于
      We don't need to set s_dirt in most of the ext4 code when journaling
      is enabled.  In ext3/4 some of the summary statistics for # of free
      inodes, blocks, and directories are calculated from the per-block
      group statistics when the file system is mounted or unmounted.  As a
      result the superblock doesn't have to be updated, either via the
      journal or by setting s_dirt.  There are a few exceptions, most
      notably when resizing the file system, where the superblock needs to
      be modified --- and in that case it should be done as a journalled
      operation if possible, and s_dirt set only in no-journal mode.
      
      This patch will optimize out some unneeded disk writes when using ext4
      with a journal.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      a0375156
  8. 28 5月, 2010 1 次提交
  9. 17 5月, 2010 8 次提交
  10. 06 3月, 2010 1 次提交
  11. 04 3月, 2010 1 次提交
  12. 03 3月, 2010 1 次提交
  13. 05 3月, 2010 1 次提交
    • J
      ext4: use ext4_get_block_write in buffer write · 744692dc
      Jiaying Zhang 提交于
      Allocate uninitialized extent before ext4 buffer write and
      convert the extent to initialized after io completes.
      The purpose is to make sure an extent can only be marked
      initialized after it has been written with new data so
      we can safely drop the i_mutex lock in ext4 DIO read without
      exposing stale data. This helps to improve multi-thread DIO
      read performance on high-speed disks.
      
      Skip the nobh and data=journal mount cases to make things simple for now.
      Signed-off-by: NJiaying Zhang <jiayingz@google.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      744692dc
  14. 03 3月, 2010 1 次提交
  15. 24 2月, 2010 1 次提交
  16. 17 2月, 2010 1 次提交
    • T
      percpu: add __percpu sparse annotations to fs · 003cb608
      Tejun Heo 提交于
      Add __percpu sparse annotations to fs.
      
      These annotations are to make sparse consider percpu variables to be
      in a different address space and warn if accessed without going
      through percpu accessors.  This patch doesn't affect normal builds.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Alex Elder <aelder@sgi.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      003cb608
  17. 16 2月, 2010 1 次提交
  18. 25 1月, 2010 2 次提交
  19. 15 1月, 2010 1 次提交
  20. 25 1月, 2010 1 次提交
  21. 01 1月, 2010 1 次提交
    • T
      ext4: Calculate metadata requirements more accurately · 9d0be502
      Theodore Ts'o 提交于
      In the past, ext4_calc_metadata_amount(), and its sub-functions
      ext4_ext_calc_metadata_amount() and ext4_indirect_calc_metadata_amount()
      badly over-estimated the number of metadata blocks that might be
      required for delayed allocation blocks.  This didn't matter as much
      when functions which managed the reserved metadata blocks were more
      aggressive about dropping reserved metadata blocks as delayed
      allocation blocks were written, but unfortunately they were too
      aggressive.  This was fixed in commit 0637c6f4, but as a result the
      over-estimation by ext4_calc_metadata_amount() would lead to reserving
      2-3 times the number of pending delayed allocation blocks as
      potentially required metadata blocks.  So if there are 1 megabytes of
      blocks which have been not yet been allocation, up to 3 megabytes of
      space would get reserved out of the user's quota and from the file
      system free space pool until all of the inode's data blocks have been
      allocated.
      
      This commit addresses this problem by much more accurately estimating
      the number of metadata blocks that will be required.  It will still
      somewhat over-estimate the number of blocks needed, since it must make
      a worst case estimate not knowing which physical blocks will be
      needed, but it is much more accurate than before.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      9d0be502
  22. 23 12月, 2009 1 次提交
  23. 23 1月, 2010 1 次提交
    • T
      ext4: Add block validity check when truncating indirect block mapped inodes · 1f2acb60
      Theodore Ts'o 提交于
      Add checks to ext4_free_branches() to make sure a block number found
      in an indirect block are valid before trying to free it.  If a bad
      block number is found, stop freeing the indirect block immediately,
      since the file system is corrupt and we will need to run fsck anyway.
      This also avoids spamming the logs, and specifically avoids
      driver-level "attempt to access beyond end of device" errors obscure
      what is really going on.
      
      If you get *really*, *really*, *really* unlucky, without this patch, a
      supposed indirect block containing garbage might contain a reference
      to a primary block group descriptor, in which case
      ext4_free_branches() could end up zero'ing out a block group
      descriptor block, and if then one of the block bitmaps for a block
      group described by that bg descriptor block is not in memory, and is
      read in by ext4_read_block_bitmap().  This function calls
      ext4_valid_block_bitmap(), which assumes that bg_inode_table() was
      validated at mount time and hasn't been modified since.  Since this
      assumption is no longer valid, it's possible for the value
      (ext4_inode_table(sb, desc) - group_first_block) to go negative, which
      will cause ext4_find_next_zero_bit() to trigger a kernel GPF.
      
      Addresses-Google-Bug: #2220436
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      1f2acb60
  24. 05 2月, 2010 1 次提交
  25. 09 12月, 2009 1 次提交