1. 28 3月, 2013 3 次提交
    • J
      Btrfs: fix space accounting for unlink and rename · 6e137ed3
      Josef Bacik 提交于
      We are way over-reserving for unlink and rename.  Rename is just some random
      huge number and unlink accounts for tree log operations that don't actually
      happen during unlink, not to mention the tree log doesn't take from the trans
      block rsv anyway so it's completely useless.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      6e137ed3
    • J
      Btrfs: fix space leak when we fail to reserve metadata space · f4881bc7
      Josef Bacik 提交于
      Dave reported a warning when running xfstest 275.  We have been leaking delalloc
      metadata space when our reservations fail.  This is because we were improperly
      calculating how much space to free for our checksum reservations.  The problem
      is we would sometimes free up space that had already been freed in another
      thread and we would end up with negative usage for the delalloc space.  This
      patch fixes the problem by calculating how much space the other threads would
      have already freed, and then calculate how much space we need to free had we not
      done the reservation at all, and then freeing any excess space.  This makes
      xfstests 275 no longer have leaked space.  Thanks
      
      Cc: stable@vger.kernel.org
      Reported-by: NDavid Sterba <dsterba@suse.cz>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      f4881bc7
    • J
      Btrfs: fix EIO from btrfs send in is_extent_unchanged for punched holes · adaa4b8e
      Jan Schmidt 提交于
      When you take a snapshot, punch a hole where there has been data, then take
      another snapshot and try to send an incremental stream, btrfs send would
      give you EIO. That is because is_extent_unchanged had no support for holes
      being punched. With this patch, instead of returning EIO we just return
      0 (== the extent is not unchanged) and we're good.
      Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
      Cc: Alexander Block <ablock84@gmail.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      adaa4b8e
  2. 27 3月, 2013 1 次提交
    • C
      Btrfs: fix race between mmap writes and compression · 4adaa611
      Chris Mason 提交于
      Btrfs uses page_mkwrite to ensure stable pages during
      crc calculations and mmap workloads.  We call clear_page_dirty_for_io
      before we do any crcs, and this forces any application with the file
      mapped to wait for the crc to finish before it is allowed to change
      the file.
      
      With compression on, the clear_page_dirty_for_io step is happening after
      we've compressed the pages.  This means the applications might be
      changing the pages while we are compressing them, and some of those
      modifications might not hit the disk.
      
      This commit adds the clear_page_dirty_for_io before compression starts
      and makes sure to redirty the page if we have to fallback to
      uncompressed IO as well.
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      Reported-by: NAlexandre Oliva <oliva@gnu.org>
      cc: stable@vger.kernel.org
      4adaa611
  3. 22 3月, 2013 5 次提交
  4. 16 3月, 2013 1 次提交
    • L
      Btrfs: fix warning of free_extent_map · 3b277594
      Liu Bo 提交于
      Users report that an extent map's list is still linked when it's actually
      going to be freed from cache.
      
      The story is that
      
      a) when we're going to drop an extent map and may split this large one into
      smaller ems, and if this large one is flagged as EXTENT_FLAG_LOGGING which means
      that it's on the list to be logged, then the smaller ems split from it will also
      be flagged as EXTENT_FLAG_LOGGING, and this is _not_ expected.
      
      b) we'll keep ems from unlinking the list and freeing when they are flagged with
      EXTENT_FLAG_LOGGING, because the log code holds one reference.
      
      The end result is the warning, but the truth is that we set the flag
      EXTENT_FLAG_LOGGING only during fsync.
      
      So clear flag EXTENT_FLAG_LOGGING for extent maps split from a large one.
      Reported-by: NJohannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
      Reported-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      3b277594
  5. 15 3月, 2013 6 次提交
  6. 07 3月, 2013 3 次提交
  7. 06 3月, 2013 1 次提交
  8. 05 3月, 2013 10 次提交
  9. 03 3月, 2013 1 次提交
  10. 02 3月, 2013 2 次提交
    • P
      btrfs: fixup/remove module.h usage as required · 180e001c
      Paul Gortmaker 提交于
      We want to avoid module.h where posible, since it in turn includes
      nearly all of header space.  This means removing it where it is not
      required, and using export.h where we are only exporting symbols via
      EXPORT_SYMBOL and friends.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      180e001c
    • J
      Btrfs: delete inline extents when we find them during logging · 124fe663
      Josef Bacik 提交于
      Apparently when we do inline extents we allow the data to overlap the last chunk
      of the btrfs_file_extent_item, which means that we can possibly have a
      btrfs_file_extent_item that isn't actually as large as a btrfs_file_extent_item.
      This messes with us when we try to overwrite the extent when logging new extents
      since we expect for it to be the right size.  To fix this just delete the item
      and try to do the insert again which will give us the proper sized
      btrfs_file_extent_item.  This fixes a panic where map_private_extent_buffer
      would blow up because we're trying to write past the end of the leaf.  Thanks,
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      124fe663
  11. 01 3月, 2013 7 次提交