1. 14 Mar, 2013 4 commits
  2. 07 Mar, 2013 3 commits
  3. 05 Mar, 2013 1 commit
  4. 04 Mar, 2013 10 commits
  5. 03 Mar, 2013 1 commit
  6. 01 Mar, 2013 8 commits
  7. 28 Feb, 2013 8 commits
  8. 26 Feb, 2013 5 commits
    • Qu Wenruo's avatar
      btrfs: cleanup for open-coded alignment · fda2832f
      Qu Wenruo authored
      Though most of the btrfs codes are using ALIGN macro for page alignment,
      there are still some codes using open-coded alignment like the
      following:
      ------
              u64 mask = ((u64)root->stripesize - 1);
              u64 ret = (val + mask) & ~mask;
      ------
      Or even hidden one:
      ------
              num_bytes = (end - start + blocksize) & ~(blocksize - 1);
      ------
      
      Sometimes these open-coded alignment is not so easy to understand for
      newbie like me.
      
      This commit changes the open-coded alignment to the ALIGN macro for a
      better readability.
      
      Also there is a previous patch from David Sterba with similar changes,
      but the patch is for 3.2 kernel and seems not merged.
      http://www.spinics.net/lists/linux-btrfs/msg12747.html
      
      Cc: David Sterba <dave@jikos.cz>
      Signed-off-by: default avatarQu Wenruo <quwenruo@cn.fujitsu.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      fda2832f
    • Liu Bo's avatar
      Btrfs: do not change inode flags in rename · 8c4ce81e
      Liu Bo authored
      Before we forced to change a file's NOCOW and COMPRESS flag due to
      the parent directory's, but this ends up a bad idea, because it
      confuses end users a lot about file's NOCOW status, eg. if someone
      change a file to NOCOW via 'chattr' and then rename it in the current
      directory which is without NOCOW attribute, the file will lose the
      NOCOW flag silently.
      
      This diables 'change flags in rename', so from now on we'll only
      inherit flags from the parent directory on creation stage while in
      other places we can use 'chattr' to set NOCOW or COMPRESS flags.
      Reported-by: default avatarMarios Titas <redneb8888@gmail.com>
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      8c4ce81e
    • Liu Bo's avatar
      Btrfs: use reserved space for creating a snapshot · 2382c5cc
      Liu Bo authored
      While inserting dir index and updating inode for a snapshot, we'd
      add delayed items which consume trans->block_rsv, if we don't have
      any space reserved in this trans handle, we either just return or
      reserve space again.
      
      But before creating pending snapshots during committing transaction,
      we've done a release on this trans handle, so we don't have space reserved
      in it at this stage.
      
      What we're using is block_rsv of pending snapshots which has already
      reserved well enough space for both inserting dir index and updating
      inode, so we need to set trans handle to indicate that we have space
      now.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Reviewed-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      2382c5cc
    • Alexandre Oliva's avatar
      clear chunk_alloc flag on retryable failure · a81cb9a2
      Alexandre Oliva authored
      I've experienced filesystem freezes with permanent spikes in the active
      process count for quite a while, particularly on filesystems whose
      available raw space has already been fully allocated to chunks.
      
      While looking into this, I found a pretty obvious error in
      do_chunk_alloc: it sets space_info->chunk_alloc, but if
      btrfs_alloc_chunk returns an error other than ENOSPC, it returns leaving
      that flag set, which causes any other threads waiting for
      space_info->chunk_alloc to become zero to spin indefinitely.
      
      I haven't double-checked that this patch fixes the failure I've observed
      fully (it's not exactly trivial to trigger), but it surely is a bug and
      the fix is trivial, so...  Please put it in :-)
      
      What I saw in that function also happens to explain why in some cases I
      see filesystems allocate a huge number of chunks that remain unused
      (leading to the scenario above, of not having more chunks to allocate).
      It happens for data and metadata, but not necessarily both.  I'm
      guessing some thread sets the force_alloc flag on the corresponding
      space_info, and then several threads trying to get disk space end up
      attempting to allocate a new chunk concurrently.  All of them will see
      the force_alloc flag and bump their local copy of force up to the level
      they see first, and they won't clear it even if another thread succeeds
      in allocating a chunk, thus clearing the force flag.  Then each thread
      that observed the force flag will, on its turn, force the allocation of
      a new chunk.  And any threads that come in while it does that will see
      the force flag still set and pick it up, and so on.  This sounds like a
      problem to me, but...  what should the correct behavior be?  Clear
      force_flag once we copy it to a local force?  Reset force to the
      incoming value on every loop?  Set the flag to our incoming force if we
      have it at first, clear our local flag, and move it from the space_info
      when we determined that we are the thread that's going to perform the
      allocation?
      
      btrfs: clear chunk_alloc flag on retryable failure
      
      From: Alexandre Oliva <oliva@gnu.org>
      
      If btrfs_alloc_chunk fails with e.g. ENOMEM, we exit do_chunk_alloc
      without clearing chunk_alloc in space_info.  As a result, any further
      calls to do_chunk_alloc on that filesystem will start busy-waiting for
      chunk_alloc to be cleared, but it never will be.  This patch adjusts
      do_chunk_alloc so that it clears this flag in case of an error.
      Signed-off-by: default avatarAlexandre Oliva <oliva@gnu.org>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      a81cb9a2
    • Jan Schmidt's avatar
      Btrfs: fix backref walking race with tree deletions · ca60ebfa
      Jan Schmidt authored
      When a subvolume is removed, we remove the root item from the root tree,
      while the tree blocks and backrefs remain for a while. When backref walking
      comes across one of those orphan tree blocks, it can find a backref for a
      no longer existing root. This is all good, we only must tolerate
      __resolve_indirect_ref returning an error and continue with the good refs
      found.
      Reported-by: default avatarAlex Lyakas <alex.btrfs@zadarastorage.com>
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      ca60ebfa