1. 28 Mar, 2013 4 commits
    • Josef Bacik's avatar
      Btrfs: hold the ordered operations mutex when waiting on ordered extents · db1d607d
      Josef Bacik authored
      We need to hold the ordered_operations mutex while waiting on ordered extents
      since we splice and run the ordered extents list.  We need to make sure anybody
      else who wants to wait on ordered extents does actually wait for them to be
      completed.  This will keep us from bailing out of flushing in case somebody is
      already waiting on ordered extents to complete.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      db1d607d
    • Josef Bacik's avatar
      Btrfs: fix space accounting for unlink and rename · 6e137ed3
      Josef Bacik authored
      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: default avatarJosef Bacik <jbacik@fusionio.com>
      6e137ed3
    • Josef Bacik's avatar
      Btrfs: fix space leak when we fail to reserve metadata space · f4881bc7
      Josef Bacik authored
      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: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      f4881bc7
    • Jan Schmidt's avatar
      Btrfs: fix EIO from btrfs send in is_extent_unchanged for punched holes · adaa4b8e
      Jan Schmidt authored
      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: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Cc: Alexander Block <ablock84@gmail.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      adaa4b8e
  2. 26 Mar, 2013 1 commit
    • Chris Mason's avatar
      Btrfs: fix race between mmap writes and compression · 4adaa611
      Chris Mason authored
      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: default avatarChris Mason <chris.mason@fusionio.com>
      Reported-by: default avatarAlexandre Oliva <oliva@gnu.org>
      cc: stable@vger.kernel.org
      4adaa611
  3. 21 Mar, 2013 5 commits
  4. 16 Mar, 2013 1 commit
    • Liu Bo's avatar
      Btrfs: fix warning of free_extent_map · 3b277594
      Liu Bo authored
      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: default avatarJohannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
      Reported-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      3b277594
  5. 14 Mar, 2013 6 commits
  6. 07 Mar, 2013 3 commits
  7. 05 Mar, 2013 1 commit
  8. 04 Mar, 2013 10 commits
  9. 03 Mar, 2013 1 commit
  10. 01 Mar, 2013 8 commits