1. 26 Jul, 2016 29 commits
  2. 21 Jul, 2016 1 commit
    • Chris Mason's avatar
      Btrfs: fix delalloc accounting after copy_from_user faults · 8b8b08cb
      Chris Mason authored
      Commit 56244ef1 was almost but not quite enough to fix the
      reservation math after btrfs_copy_from_user returned partial copies.
      
      Some users are still seeing warnings in btrfs_destroy_inode, and with a
      long enough test run I'm able to trigger them as well.
      
      This patch fixes the accounting math again, bringing it much closer to
      the way it was before the sectorsize conversion Chandan did.  The
      problem is accounting for the offset into the page/sector when we do a
      partial copy.  This one just uses the dirty_sectors variable which
      should already be updated properly.
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      cc: stable@vger.kernel.org # v4.6+
      8b8b08cb
  3. 20 Jul, 2016 2 commits
  4. 07 Jul, 2016 8 commits
    • Josef Bacik's avatar
      Btrfs: use FLUSH_LIMIT for relocation in reserve_metadata_bytes · 8ca17f0f
      Josef Bacik authored
      We used to allow you to set FLUSH_ALL and then just wouldn't do things like
      commit transactions or wait on ordered extents if we noticed you were in a
      transaction.  However now that all the flushing for FLUSH_ALL is asynchronous
      we've lost the ability to tell, and we could end up deadlocking.  So instead use
      FLUSH_LIMIT in reserve_metadata_bytes in relocation and then return -EAGAIN if
      we error out to preserve the previous behavior.  I've also added an ASSERT() to
      catch anybody else who tries to do this.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      8ca17f0f
    • Josef Bacik's avatar
      Btrfs: fill relocation block rsv after allocation · ac2fabac
      Josef Bacik authored
      Since we set the reloc control before we've reserved our space for relocation we
      could race with a root being dirtied and not actually have space to do our init
      reloc root.  So once we've allocated it and set it up go ahead and make our
      reservation before setting the relocate control, that way anybody who tries to
      do the reloc root init has space to use.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      ac2fabac
    • Josef Bacik's avatar
      Btrfs: always use trans->block_rsv for orphans · 40acc3ee
      Josef Bacik authored
      This is the case all the time anyway except for relocation which could be doing
      a reloc root for a non ref counted root, in which case we'd end up with some
      random block rsv rather than the one we have our reservation in.  If there isn't
      enough space in the block rsv we are trying to steal from we'll BUG() because we
      expect there to be space for the orphan to make its reservation.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      40acc3ee
    • Josef Bacik's avatar
      Btrfs: change how we calculate the global block rsv · ae2e4728
      Josef Bacik authored
      Traditionally we've calculated the global block rsv by guessing how much of the
      metadata used amount was the extent tree, and then taking the data size and
      figuring out how large the csum tree would have to be to hold that much data.
      
      This is imprecise and falls down on MIXED file systems as we can't trust the
      data used amount.  This resulted in failures for xfstests generic/333 because it
      creates lots of clones, which explodes out the extent tree.  Our global reserve
      calculations were woefully inaccurate in this case which meant we got into a
      situation where we did not have enough reserved to do our work.
      
      We know we only use the global block rsv for the extent, csum, and root trees,
      so just get the bytes used for these trees and use that as the basis of our
      global reserve.  Since these are not reference counted trees the bytes_used
      value will be accurate.  This fixed the transaction aborts seen with
      generic/333.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      ae2e4728
    • Josef Bacik's avatar
      Btrfs: use root when checking need_async_flush · 87241c2e
      Josef Bacik authored
      Instead of doing fs_info->fs_root in need_async_flush, which may not be set
      during recovery when mounting, just pass the root itself in, which makes more
      sense as thats what btrfs_calc_reclaim_metadata_size takes.
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Reported-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      87241c2e
    • Josef Bacik's avatar
      Btrfs: don't bother kicking async if there's nothing to reclaim · d38b349c
      Josef Bacik authored
      We do this check when we start the async reclaimer thread, might as well check
      before we kick it off to save us some cycles.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      d38b349c
    • Josef Bacik's avatar
      Btrfs: fix release reserved extents trace points · 31bada7c
      Josef Bacik authored
      We were doing trace_btrfs_release_reserved_extent() in pin_down_extent which
      isn't quite right because we will go through and free that extent later when we
      unpin, so it messes up apps that are accounting for the reservation space.  We
      were also unconditionally doing it in __btrfs_free_reserved_extent(), when we
      only actually free the reservation instead of pinning the extent.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      31bada7c
    • Josef Bacik's avatar
      Btrfs: add fsid to some tracepoints · dce3afa5
      Josef Bacik authored
      When tracing enospc problems on a box with multiple file systems mounted I need
      to be able to differentiate between the two file systems.  Most of the important
      trace points I'm looking at already have an fsid, but the reserved extent trace
      points do not, so add that to make it possible to figure out which trace point
      belongs to which file system.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      dce3afa5