1. 14 3月, 2011 11 次提交
  2. 13 3月, 2011 3 次提交
  3. 12 3月, 2011 1 次提交
    • C
      Btrfs: break out of shrink_delalloc earlier · 36e39c40
      Chris Mason 提交于
      Josef had changed shrink_delalloc to exit after three shrink
      attempts, which wasn't quite enough because new writers could
      race in and steal free space.
      
      But it also fixed deadlocks and stalls as we tried to recover
      delalloc reservations.  The code was tweaked to loop 1024
      times, and would reset the counter any time a small amount
      of progress was made.  This was too drastic, and with a
      lot of writers we can end up stuck in shrink_delalloc forever.
      
      The shrink_delalloc loop is fairly complex because the caller is looping
      too, and the caller will go ahead and force a transaction commit to make
      sure we reclaim space.
      
      This reworks things to exit shrink_delalloc when we've forced some
      writeback and the delalloc reservations have gone down.  This means
      the writeback has not just started but has also finished at
      least some of the metadata changes required to reclaim delalloc
      space.
      
      If we've got this wrong, we're returning ENOSPC too early, which
      is a big improvement over the current behavior of hanging the machine.
      
      Test 224 in xfstests hammers on this nicely, and with 1000 writers
      trying to fill a 1GB drive we get our first ENOSPC at 93% full.  The
      other writers are able to continue until we get 100%.
      
      This is a worst case test for btrfs because the 1000 writers are doing
      small IO, and the small FS size means we don't have a lot of room
      for metadata chunks.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      36e39c40
  4. 11 3月, 2011 22 次提交
  5. 10 3月, 2011 3 次提交
    • T
      Merge branch 'for-2.6.38' of... · db72f3fc
      Takashi Iwai 提交于
      Merge branch 'for-2.6.38' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into fix/asoc
      db72f3fc
    • J
      fs/dcache: allow d_obtain_alias() to return unhashed dentries · d891eedb
      J. Bruce Fields 提交于
      Without this patch, inodes are not promptly freed on last close of an
      unlinked file by an nfs client:
      
      	client$ mount -tnfs4 server:/export/ /mnt/
      	client$ tail -f /mnt/FOO
      	...
      	server$ df -i /export
      	server$ rm /export/FOO
      	(^C the tail -f)
      	server$ df -i /export
      	server$ echo 2 >/proc/sys/vm/drop_caches
      	server$ df -i /export
      
      the df's will show that the inode is not freed on the filesystem until
      the last step, when it could have been freed after killing the client's
      tail -f. On-disk data won't be deallocated either, leading to possible
      spurious ENOSPC.
      
      This occurs because when the client does the close, it arrives in a
      compound with a putfh and a close, processed like:
      
      	- putfh: look up the filehandle.  The only alias found for the
      	  inode will be DCACHE_UNHASHED alias referenced by the filp
      	  this, so it creates a new DCACHE_DISCONECTED dentry and
      	  returns that instead.
      	- close: closes the existing filp, which is destroyed
      	  immediately by dput() since it's DCACHE_UNHASHED.
      	- end of the compound: release the reference
      	  to the current filehandle, and dput() the new
      	  DCACHE_DISCONECTED dentry, which gets put on the
      	  unused list instead of being destroyed immediately.
      
      Nick Piggin suggested fixing this by allowing d_obtain_alias to return
      the unhashed dentry that is referenced by the filp, instead of making it
      create a new dentry.
      
      Leave __d_find_alias() alone to avoid changing behavior of other
      callers.
      
      Also nfsd doesn't need all the checks of __d_find_alias(); any dentry,
      hashed or unhashed, disconnected or not, should work.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d891eedb
    • M
      Check for immutable/append flag in fallocate path · 1ca551c6
      Marco Stornelli 提交于
      In the fallocate path the kernel doesn't check for the immutable/append
      flag. It's possible to have a race condition in this scenario: an
      application open a file in read/write and it does something, meanwhile
      root set the immutable flag on the file, the application at that point
      can call fallocate with success. In addition, we don't allow to do any
      unreserve operation on an append only file but only the reserve one.
      Signed-off-by: NMarco Stornelli <marco.stornelli@gmail.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1ca551c6