1. 02 Mar, 2013 2 commits
  2. 18 Feb, 2013 2 commits
    • Zheng Liu's avatar
      ext4: reclaim extents from extent status tree · 74cd15cd
      Zheng Liu authored
      
      
      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: default avatarZheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: Jan kara <jack@suse.cz>
      74cd15cd
    • Zheng Liu's avatar
      ext4: remove single extent cache · 69eb33dc
      Zheng Liu authored
      
      
      Single extent cache could be removed because we have extent status tree
      as a extent cache, and it would be better.
      Signed-off-by: default avatarZheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: Jan kara <jack@suse.cz>
      69eb33dc
  3. 09 Feb, 2013 1 commit
    • Theodore Ts'o's avatar
      ext4: pass context information to jbd2__journal_start() · 9924a92a
      Theodore Ts'o authored
      
      
      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: default avatar"Theodore Ts'o" <tytso@mit.edu>
      9924a92a
  4. 08 Feb, 2013 1 commit
  5. 03 Feb, 2013 4 commits
  6. 29 Jan, 2013 1 commit
  7. 28 Jan, 2013 2 commits
  8. 25 Jan, 2013 2 commits
  9. 13 Jan, 2013 1 commit
  10. 27 Dec, 2012 1 commit
  11. 25 Dec, 2012 2 commits
  12. 20 Dec, 2012 1 commit
  13. 10 Dec, 2012 4 commits
    • Carlos Maiolino's avatar
      ext4: ensure Inode flags consistency are checked at build time · 9a4c8019
      Carlos Maiolino authored
      
      
      
      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: default avatarCarlos Maiolino <cmaiolino@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      9a4c8019
    • Tao Ma's avatar
      ext4: Remove CONFIG_EXT4_FS_XATTR · 939da108
      Tao Ma authored
      
      
      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: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTao Ma <boyu.mt@taobao.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      939da108
    • Guo Chao's avatar
      ext4: remove redundant initialization in ext4_fill_super() · 6b280c91
      Guo Chao authored
      
      
      We use kzalloc() to allocate sbi, no need to zero its field.
      Signed-off-by: default avatarGuo Chao <yan@linux.vnet.ibm.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      6b280c91
    • Guo Chao's avatar
      ext4: remove redundant code in ext4_alloc_inode() · a789f49c
      Guo Chao authored
      
      
      inode_init_always() will initialize inode->i_data.writeback_index
      anyway, no need to do this in ext4_alloc_inode().
      Signed-off-by: default avatarGuo Chao <yan@linux.vnet.ibm.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: default avatarLukas Czerner <lczerner@redhat.com>
      a789f49c
  14. 28 Nov, 2012 2 commits
    • Theodore Ts'o's avatar
      ext4: rationalize ext4_extents.h inclusion · 4a092d73
      Theodore Ts'o authored
      
      
      Previously, ext4_extents.h was being included at the end of ext4.h,
      which was bad for a number of reasons: (a) it was not being included
      in the expected place, and (b) it caused the header to be included
      multiple times.  There were #ifdef's to prevent this from causing any
      problems, but it still was unnecessary.
      
      By moving the function declarations that were in ext4_extents.h to
      ext4.h, which is standard practice for where the function declarations
      for the rest of ext4.h can be found, we can remove ext4_extents.h from
      being included in ext4.h at all, and then we can only include
      ext4_extents.h where it is needed in ext4's source files.
      
      It should be possible to move a few more things into ext4.h, and
      further reduce the number of source files that need to #include
      ext4_extents.h, but that's a cleanup for another day.
      Reported-by: default avatarSachin Kamat <sachin.kamat@linaro.org>
      Reported-by: default avatarWei Yongjun <weiyj.lk@gmail.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      4a092d73
    • Vahram Martirosyan's avatar
      ext4: fixed potential NULL dereference in ext4_calculate_overhead() · 766f44d4
      Vahram Martirosyan authored
      
      
      The memset operation before check can cause a BUG if the memory
      allocation failed.  Since we are using get_zeroed_age, there is no
      need to use memset anyway.
      
      Found by the Spruce system in cooperation with the KEDR Framework.
      Signed-off-by: default avatarVahram Martirosyan <vmartirosyan@linuxtesting.org>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      766f44d4
  15. 09 Nov, 2012 2 commits
  16. 08 Nov, 2012 4 commits
  17. 15 Oct, 2012 1 commit
  18. 10 Oct, 2012 1 commit
    • Theodore Ts'o's avatar
      ext4: fix metadata checksum calculation for the superblock · 06db49e6
      Theodore Ts'o authored
      
      
      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: default avatarGeorge Spelvin <linux@horizon.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      06db49e6
  19. 03 Oct, 2012 1 commit
  20. 29 Sep, 2012 2 commits
  21. 27 Sep, 2012 2 commits
  22. 24 Sep, 2012 1 commit