1. 04 3月, 2010 7 次提交
  2. 02 3月, 2010 1 次提交
  3. 03 3月, 2010 2 次提交
  4. 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
  5. 03 3月, 2010 1 次提交
  6. 02 3月, 2010 7 次提交
  7. 25 2月, 2010 1 次提交
  8. 24 2月, 2010 1 次提交
  9. 17 2月, 2010 1 次提交
    • C
      ext4: Fix BUG_ON at fs/buffer.c:652 in no journal mode · 73b50c1c
      Curt Wohlgemuth 提交于
      Calls to ext4_handle_dirty_metadata should only pass in an inode
      pointer for inode-specific metadata, and not for shared metadata
      blocks such as inode table blocks, block group descriptors, the
      superblock, etc.
      
      The BUG_ON can get tripped when updating a special device (such as a
      block device) that is opened (so that i_mapping is set in
      fs/block_dev.c) and the file system is mounted in no journal mode.
      
      Addresses-Google-Bug: #2404870
      Signed-off-by: NCurt Wohlgemuth <curtw@google.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      73b50c1c
  10. 05 3月, 2010 1 次提交
  11. 16 2月, 2010 2 次提交
  12. 25 1月, 2010 2 次提交
  13. 01 1月, 2010 1 次提交
  14. 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
  15. 16 2月, 2010 1 次提交
    • E
      ext4: Fix optional-arg mount options · 15121c18
      Eric Sandeen 提交于
      We have 2 mount options, "barrier" and "auto_da_alloc" which may or
      may not take a 1/0 argument.  This causes the ext4 superblock mount
      code to subtract uninitialized pointers and pass the result to
      kmalloc, which results in very noisy failures.
      
      Per Ted's suggestion, initialize the args struct so that
      we know whether match_token() found an argument for the
      option, and skip match_int() if not.
      
      Also, return error (0) from parse_options if we thought
      we found an argument, but match_int() Fails.
      Reported-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      15121c18
  16. 05 2月, 2010 1 次提交
  17. 15 1月, 2010 1 次提交
  18. 25 1月, 2010 1 次提交
  19. 23 1月, 2010 1 次提交
  20. 01 1月, 2010 2 次提交
    • 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
    • T
      ext4: Fix accounting of reserved metadata blocks · ee5f4d9c
      Theodore Ts'o 提交于
      Commit 0637c6f4 had a typo which caused the reserved metadata blocks to
      not be released correctly.   Fix this.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      ee5f4d9c
  21. 31 12月, 2009 1 次提交
    • T
      ext4: Patch up how we claim metadata blocks for quota purposes · 0637c6f4
      Theodore Ts'o 提交于
      As reported in Kernel Bugzilla #14936, commit d21cd8f1 triggered a BUG
      in the function ext4_da_update_reserve_space() found in
      fs/ext4/inode.c.  The root cause of this BUG() was caused by the fact
      that ext4_calc_metadata_amount() can severely over-estimate how many
      metadata blocks will be needed, especially when using direct
      block-mapped files.
      
      In addition, it can also badly *under* estimate how much space is
      needed, since ext4_calc_metadata_amount() assumes that the blocks are
      contiguous, and this is not always true.  If the application is
      writing blocks to a sparse file, the number of metadata blocks
      necessary can be severly underestimated by the functions
      ext4_da_reserve_space(), ext4_da_update_reserve_space() and
      ext4_da_release_space().  This was the cause of the dq_claim_space
      reports found on kerneloops.org.
      
      Unfortunately, doing this right means that we need to massively
      over-estimate the amount of free space needed.  So in some cases we
      may need to force the inode to be written to disk asynchronously in
      to avoid spurious quota failures.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=14936Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      0637c6f4
  22. 30 12月, 2009 1 次提交
  23. 26 12月, 2009 1 次提交
  24. 23 12月, 2009 1 次提交
    • E
      ext4: flush delalloc blocks when space is low · c8afb446
      Eric Sandeen 提交于
      Creating many small files in rapid succession on a small
      filesystem can lead to spurious ENOSPC; on a 104MB filesystem:
      
      for i in `seq 1 22500`; do
          echo -n > $SCRATCH_MNT/$i
          echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i
      done
      
      leads to ENOSPC even though after a sync, 40% of the fs is free
      again.
      
      This is because we reserve worst-case metadata for delalloc writes,
      and when data is allocated that worst-case reservation is not
      usually needed.
      
      When freespace is low, kicking off an async writeback will start
      converting that worst-case space usage into something more realistic,
      almost always freeing up space to continue.
      
      This resolves the testcase for me, and survives all 4 generic
      ENOSPC tests in xfstests.
      
      We'll still need a hard synchronous sync to squeeze out the last bit,
      but this fixes things up to a large degree.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      c8afb446