1. 21 2月, 2013 5 次提交
    • J
      Btrfs: rework the overcommit logic to be based on the total size · 70afa399
      Josef Bacik 提交于
      People have been complaining about random ENOSPC errors that will clear up
      after a umount or just a given amount of time.  Chris was able to reproduce
      this with stress.sh and lots of processes and so was I.  Basically the
      overcommit stuff would really let us get out of hand, in my tests I saw up
      to 30 gigs of outstanding reservations with only 2 gigs total of metadata
      space.  This usually worked out fine but with so much outstanding
      reservation the flushing stuff short circuits to make sure we don't hang
      forever flushing when we really need ENOSPC.  Plus we allocate chunks in
      order to alleviate the pressure, but this doesn't actually help us since we
      only use the non-allocated area in our over commit logic.
      
      So instead of basing overcommit on the amount of non-allocated space,
      instead just do it based on how much total space we have, and then limit it
      to the non-allocated space in case we are short on space to spill over into.
      This allows us to have the same performance as well as no longer giving
      random ENOSPC.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      70afa399
    • E
      btrfs: remove unnecessary DEFINE_WAIT() declarations · 1971e917
      Eric Sandeen 提交于
      No point in DEFINE_WAIT(wait) if it's not used!
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      1971e917
    • J
      Btrfs: do not overcommit if we don't have enough space for global rsv · 96f1bb57
      Josef Bacik 提交于
      Because of how little we allocate chunks now we can get really tight on
      metadata space before we will allocate a new chunk.  This resulted in being
      unable to add device extents when allocating a new metadata chunk as we did
      not have enough space.  This is because we were allowed to overcommit too
      much metadata without actually making sure we had enough space to make
      allocations.  The idea behind overcommit is that we are allowed to say "sure
      you can have that reservation" when most of the free space is occupied by
      reservations, not actual allocations.  But in this case where a majority of
      the total space is in use by actual allocations we can screw ourselves by
      not being able to make real allocations when it matters.  So make sure we
      have enough real space for our global reserve, and if not then don't allow
      overcommitting.  Thanks,
      Reported-and-tested-by: NJim Schutt <jaschut@sandia.gov>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      96f1bb57
    • M
      Btrfs: use seqlock to protect fs_info->avail_{data, metadata, system}_alloc_bits · de98ced9
      Miao Xie 提交于
      There is no lock to protect
        fs_info->avail_{data, metadata, system}_alloc_bits,
      it may introduce some problem, such as the wrong profile
      information, so we add a seqlock to protect them.
      Signed-off-by: NZhao Lei <zhaolei@cn.fujitsu.com>
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      de98ced9
    • M
      Btrfs: use percpu counter for fs_info->delalloc_bytes · 963d678b
      Miao Xie 提交于
      fs_info->delalloc_bytes is accessed very frequently, so use percpu
      counter instead of the u64 variant for it to reduce the lock
      contention.
      
      This patch also fixed the problem that we access the variant
      without the lock protection.At worst, we would not flush the
      delalloc inodes, and just return ENOSPC error when we still have
      some free space in the fs.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      963d678b
  2. 20 2月, 2013 10 次提交
  3. 06 2月, 2013 1 次提交
  4. 15 1月, 2013 3 次提交
  5. 17 12月, 2012 4 次提交
  6. 13 12月, 2012 4 次提交
  7. 12 12月, 2012 4 次提交
    • J
      Btrfs: fill the global reserve when unpinning space · 7b398f8e
      Josef Bacik 提交于
      Dave gave me an image of a very full file system that would abort the
      transaction because it ran out of space while committing the transaction.
      This is because we would think there was plenty of room to create a snapshot
      even though the global reserve was not full.  This happens because we
      calculate the global reserve size before we unpin any space, so after we
      unpin the space we allow reservations to occur even though we haven't
      reserved all of the space for our global reserve.  Fix this by adding to the
      global reserve while unpinning in order to make sure we always have enough
      space to do our work.  With this patch we no longer end up with an aborted
      transaction, we return ENOSPC properly to the person trying to create the
      snapshot.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      7b398f8e
    • M
      Btrfs: improve the noflush reservation · 08e007d2
      Miao Xie 提交于
      In some places(such as: evicting inode), we just can not flush the reserved
      space of delalloc, flushing the delayed directory index and delayed inode
      is OK, but we don't try to flush those things and just go back when there is
      no enough space to be reserved. This patch fixes this problem.
      
      We defined 3 types of the flush operations: NO_FLUSH, FLUSH_LIMIT and FLUSH_ALL.
      If we can in the transaction, we should not flush anything, or the deadlock
      would happen, so use NO_FLUSH. If we flushing the reserved space of delalloc
      would cause deadlock, use FLUSH_LIMIT. In the other cases, FLUSH_ALL is used,
      and we will flush all things.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      08e007d2
    • M
      Btrfs: fix wrong comment in can_overcommit() · 561c294d
      Miao Xie 提交于
      The comment is not coincident with the code. Fix it.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      561c294d
    • M
      Btrfs: cleanup duplicated division functions · 3fed40cc
      Miao Xie 提交于
      div_factor{_fine} has been implemented for two times, cleanup it.
      And I move them into a independent file named math.h because they are
      common math functions.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      3fed40cc
  8. 09 10月, 2012 4 次提交
  9. 04 10月, 2012 2 次提交
  10. 02 10月, 2012 3 次提交
    • J
      Btrfs: remove bytes argument from do_chunk_alloc · 698d0082
      Josef Bacik 提交于
      Everybody is just making stuff up, and it's just used to see if we really do
      need to alloc a chunk, and since we do this when we already know we really
      do it's just a waste of space.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      698d0082
    • J
      Btrfs: delay block group item insertion · ea658bad
      Josef Bacik 提交于
      So we have lots of places where we try to preallocate chunks in order to
      make sure we have enough space as we make our allocations.  This has
      historically meant that we're constantly tweaking when we should allocate a
      new chunk, and historically we have gotten this horribly wrong so we way
      over allocate either metadata or data.  To try and keep this from happening
      we are going to make it so that the block group item insertion is done out
      of band at the end of a transaction.  This will allow us to create chunks
      even if we are trying to make an allocation for the extent tree.  With this
      patch my enospc tests run faster (didn't expect this) and more efficiently
      use the disk space (this is what I wanted).  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      ea658bad
    • J
      Btrfs: fix our overcommit math · a80c8dcf
      Josef Bacik 提交于
      I noticed I was seeing large lags when running my torrent test in a vm on my
      laptop.  While trying to make it lag less I noticed that our overcommit math
      was taking into account the number of bytes we wanted to reclaim, not the
      number of bytes we actually wanted to allocate, which means we wouldn't
      overcommit as often.  This patch fixes the overcommit math and makes
      shrink_delalloc() use that logic so that it will stop looping faster.  We
      still have pretty high spikes of latency, but the test now takes 3 minutes
      less time (about 5% faster).  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      a80c8dcf