1. 03 3月, 2013 2 次提交
  2. 02 3月, 2013 1 次提交
  3. 18 2月, 2013 2 次提交
    • Z
      ext4: reclaim extents from extent status tree · 74cd15cd
      Zheng Liu 提交于
      Although extent status is loaded on-demand, we also need to reclaim
      extent from the tree when we are under a heavy memory pressure because
      in some cases fragmented extent tree causes status tree costs too much
      memory.
      
      Here we maintain a lru list in super_block.  When the extent status of
      an inode is accessed and changed, this inode will be move to the tail
      of the list.  The inode will be dropped from this list when it is
      cleared.  In the inode, a counter is added to count the number of
      cached objects in extent status tree.  Here only written/unwritten/hole
      extent is counted because delayed extent doesn't be reclaimed due to
      fiemap, bigalloc and seek_data/hole need it.  The counter will be
      increased as a new extent is allocated, and it will be decreased as a
      extent is freed.
      
      In this commit we use normal shrinker framework to reclaim memory from
      the status tree.  ext4_es_reclaim_extents_count() traverses the lru list
      to count the number of reclaimable extents.  ext4_es_shrink() tries to
      reclaim written/unwritten/hole extents from extent status tree.  The
      inode that has been shrunk is moved to the tail of lru list.
      Signed-off-by: NZheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: Jan kara <jack@suse.cz>
      74cd15cd
    • Z
      ext4: remove single extent cache · 69eb33dc
      Zheng Liu 提交于
      Single extent cache could be removed because we have extent status tree
      as a extent cache, and it would be better.
      Signed-off-by: NZheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: Jan kara <jack@suse.cz>
      69eb33dc
  4. 09 2月, 2013 2 次提交
    • T
      ext4: pass context information to jbd2__journal_start() · 9924a92a
      Theodore Ts'o 提交于
      So we can better understand what bits of ext4 are responsible for
      long-running jbd2 handles, use jbd2__journal_start() so we can pass
      context information for logging purposes.
      
      The recommended way for finding the longer-running handles is:
      
         T=/sys/kernel/debug/tracing
         EVENT=$T/events/jbd2/jbd2_handle_stats
         echo "interval > 5" > $EVENT/filter
         echo 1 > $EVENT/enable
      
         ./run-my-fs-benchmark
      
         cat $T/trace > /tmp/problem-handles
      
      This will list handles that were active for longer than 20ms.  Having
      longer-running handles is bad, because a commit started at the wrong
      time could stall for those 20+ milliseconds, which could delay an
      fsync() or an O_SYNC operation.  Here is an example line from the
      trace file describing a handle which lived on for 311 jiffies, or over
      1.2 seconds:
      
      postmark-2917  [000] ....   196.435786: jbd2_handle_stats: dev 254,32 
         tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
         dirtied_blocks 0
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      9924a92a
    • T
      ext4: move the jbd2 wrapper functions out of super.c · 722887dd
      Theodore Ts'o 提交于
      Move the jbd2 wrapper functions which start and stop handles out of
      super.c, where they don't really logically belong, and into
      ext4_jbd2.c.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      722887dd
  5. 03 2月, 2013 4 次提交
  6. 29 1月, 2013 1 次提交
  7. 28 1月, 2013 2 次提交
  8. 25 1月, 2013 2 次提交
  9. 13 1月, 2013 1 次提交
  10. 27 12月, 2012 1 次提交
  11. 26 12月, 2012 2 次提交
  12. 20 12月, 2012 1 次提交
  13. 11 12月, 2012 4 次提交
    • C
      ext4: ensure Inode flags consistency are checked at build time · 9a4c8019
      Carlos Maiolino 提交于
      
      Flags being used by atomic operations in inode flags (e.g.
      ext4_test_inode_flag(), should be consistent with that actually stored
      in inodes, i.e.: EXT4_XXX_FL.
      
      It ensures that this consistency is checked at build-time, not at
      run-time.
      
      Currently, the flags consistency are being checked at run-time, but,
      there is no real reason to not do a build-time check instead of a
      run-time check. The code is comparing macro defined values with enum
      type variables, where both are constants, so, there is no problem in
      comparing constants at build-time.
      
      enum variables are treated as constants by the C compiler, according
      to the C99 specs (see www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf 
      sec. 6.2.5, item 16), so, there is no real problem in comparing an
      enumeration type at build time
      Signed-off-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      9a4c8019
    • T
      ext4: Remove CONFIG_EXT4_FS_XATTR · 939da108
      Tao Ma 提交于
      Ted has sent out a RFC about removing this feature. Eric and Jan
      confirmed that both RedHat and SUSE enable this feature in all their
      product.  David also said that "As far as I know, it's enabled in all
      Android kernels that use ext4."  So it seems OK for us.
      
      And what's more, as inline data depends its implementation on xattr,
      and to be frank, I don't run any test again inline data enabled while
      xattr disabled.  So I think we should add inline data and remove this
      config option in the same release.
      
      [ The savings if you disable CONFIG_EXT4_FS_XATTR is only 27k, which
        isn't much in the grand scheme of things.  Since no one seems to be
        testing this configuration except for some automated compile farms, on
        balance we are better removing this config option, and so that it is
        effectively always enabled. -- tytso ]
      
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      939da108
    • G
      ext4: remove redundant initialization in ext4_fill_super() · 6b280c91
      Guo Chao 提交于
      We use kzalloc() to allocate sbi, no need to zero its field.
      Signed-off-by: NGuo Chao <yan@linux.vnet.ibm.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      6b280c91
    • G
      ext4: remove redundant code in ext4_alloc_inode() · a789f49c
      Guo Chao 提交于
      inode_init_always() will initialize inode->i_data.writeback_index
      anyway, no need to do this in ext4_alloc_inode().
      Signed-off-by: NGuo Chao <yan@linux.vnet.ibm.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: NLukas Czerner <lczerner@redhat.com>
      a789f49c
  14. 29 11月, 2012 2 次提交
  15. 09 11月, 2012 5 次提交
  16. 08 11月, 2012 1 次提交
  17. 16 10月, 2012 1 次提交
  18. 10 10月, 2012 1 次提交
    • T
      ext4: fix metadata checksum calculation for the superblock · 06db49e6
      Theodore Ts'o 提交于
      The function ext4_handle_dirty_super() was calculating the superblock
      on the wrong block data.  As a result, when the superblock is modified
      while it is mounted (most commonly, when inodes are added or removed
      from the orphan list), the superblock checksum would be wrong.  We
      didn't notice because the superblock *was* being correctly calculated
      in ext4_commit_super(), and this would get called when the file system
      was unmounted.  So the problem only became obvious if the system
      crashed while the file system was mounted.
      
      Fix this by removing the poorly designed function signature for
      ext4_superblock_csum_set(); if it only took a single argument, the
      pointer to a struct superblock, the ambiguity which caused this
      mistake would have been impossible.
      Reported-by: NGeorge Spelvin <linux@horizon.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      06db49e6
  19. 03 10月, 2012 1 次提交
  20. 29 9月, 2012 2 次提交
  21. 27 9月, 2012 2 次提交