Skip to content

L
linux

xiphi1978 / linux

通知 2
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 18 6月, 2011 2 次提交
  3. 16 6月, 2011 3 次提交
    • J
      Btrfs: set no_trans_join after trying to expand the transaction · ed0ca140
      由 Josef Bacik 提交于 
      We can lockup if we try to allow new writers join the transaction and we have
flushoncommit set or have a pending snapshot.  This is because we set
no_trans_join and then loop around and try to wait for ordered extents again.
The problem is the ordered endio stuff needs to join the transaction, which it
can't do because no_trans_join is set.  So instead wait until after this loop to
set no_trans_join and then make sure to wait for num_writers == 1 in case
anybody got started in between us exiting the loop and setting no_trans_join.
This could easily be reproduced by mounting -o flushoncommit and running xfstest
13.  It cannot be reproduced with this patch.  Thanks,
Reported-by: NJim Schutt <jaschut@sandia.gov>
Signed-off-by: NJosef Bacik <josef@redhat.com>
      ed0ca140
    • J
      Btrfs: protect the pending_snapshots list with trans_lock · 8351583e
      由 Josef Bacik 提交于 
      Currently there is nothing protecting the pending_snapshots list on the
transaction.  We only hold the directory mutex that we are snapshotting and a
read lock on the subvol_sem, so we could race with somebody else creating a
snapshot in a different directory and end up with list corruption.  So protect
this list with the trans_lock.  Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      8351583e
    • J
      Btrfs: fix path leakage on subvol deletion · 71d7aed0
      由 Josef Bacik 提交于 
      The delayed ref patch accidently removed the btrfs_free_path in
btrfs_unlink_subvol, this puts it back and means we don't leak a path.  Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      71d7aed0
  5. 13 6月, 2011 2 次提交
  7. 11 6月, 2011 9 次提交
  9. 10 6月, 2011 4 次提交
  11. 09 6月, 2011 8 次提交
    • J
      Btrfs: unlock the trans lock properly · 3473f3c0
      由 Josef Bacik 提交于 
      In btrfs_wait_for_commit if we came upon a transaction that had committed we
just exited, but that's bad since we are holding the trans_lock.  So break
instead so that the lock is dropped.  Thanks,
Reported-by: NDavid Sterba <dsterba@suse.cz>
Signed-off-by: NJosef Bacik <josef@redhat.com>
      3473f3c0
    • J
      Btrfs: don't map extent buffer if path->skip_locking is set · 25b8b936
      由 Josef Bacik 提交于 
      Arne's scrub stuff exposed a problem with mapping the extent buffer in
reada_for_search.  He searches the commit root with multiple threads and with
skip_locking set, so we can race and overwrite node->map_token since node isn't
locked.  So fix this so that we only map the extent buffer if we don't already
have a map_token and skip_locking isn't set.  Without this patch scrub would
panic almost immediately, with the patch it doesn't panic anymore.  Thanks,
Reported-by: NArne Jansen <sensille@gmx.net>
Signed-off-by: NJosef Bacik <josef@redhat.com>
      25b8b936
    • J
      Btrfs: fix duplicate checking logic · f6a39829
      由 Josef Bacik 提交于 
      When merging my code into the integration test the second check for duplicate
entries got screwed up.  This patch fixes it by dropping ret2 and just using ret
for the return value, and checking if we got an error before adding the bitmap
to the local list.  Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      f6a39829
    • J
      Btrfs: fix the allocator loop logic · 723bda20
      由 Josef Bacik 提交于 
      I was testing with empty_cluster = 0 to try and reproduce a problem and kept
hitting early enospc panics.  This was because our loop logic was a little
confused.  So this is what I did

1) Make the loop variable the ultimate decider on wether we should loop again
isntead of checking to see if we had an uncached bg, empty size or empty
cluster.

2) Increment loop before checking to see what we are on to make the loop
definitions make more sense.

3) If we are on the chunk alloc loop don't set empty_size/empty_cluster to 0
unless we didn't actually allocate a chunk.  If we did allocate a chunk we
should be able to easily setup a new cluster so clearing
empty_size/empty_cluster makes us less efficient.

This kept me from hitting panics while trying to reproduce the other problem.
Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      723bda20
    • J
      Btrfs: fix bitmap regression · 2cdc342c
      由 Josef Bacik 提交于 
      In cleaning up the clustering code I accidently introduced a regression by
adding bitmap entries to the cluster rb tree.  The problem is if we've maxed out
the number of bitmaps we can have for the block group we can only add free space
to the bitmaps, but since the bitmap is on the cluster we can't find it and we
try to create another one.  This would result in a panic because the total
bitmaps was bigger than the max bitmaps that were allowed.  This patch fixes
this by checking to see if we have a cluster, and then looking at the cluster rb
tree to see if it has a bitmap entry and if it does and that space belongs to
that bitmap, go ahead and add it to that bitmap.

I could hit this panic every time with an fs_mark test within a couple of
minutes.  With this patch I no longer hit the panic and fs_mark goes to
completion.  Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      2cdc342c
    • J
      Btrfs: don't commit the transaction if we dont have enough pinned bytes · f2bb8f5c
      由 Josef Bacik 提交于 
      I noticed when running an enospc test that we would get stuck committing the
transaction in check_data_space even though we truly didn't have enough space.
So check to see if bytes_pinned is bigger than num_bytes, if it's not don't
commit the transaction.  Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      f2bb8f5c
    • J
      Btrfs: noinline the cluster searching functions · 3de85bb9
      由 Josef Bacik 提交于 
      When profiling the find cluster code it's hard to tell where we are spending our
time because the bitmap and non-bitmap functions get inlined by the compiler, so
make that not happen.  Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      3de85bb9
    • J
      Btrfs: cache bitmaps when searching for a cluster · 86d4a77b
      由 Josef Bacik 提交于 
      If we are looking for a cluster in a particularly sparse or fragmented block
group, we will do a lot of looping through the free space tree looking for
various things, and if we need to look at bitmaps we will endup doing the whole
dance twice.  So instead add the bitmap entries to a temporary list so if we
have to do the bitmap search we can just look through the list of entries we've
found quickly instead of having to loop through the entire tree again.  Thanks,
Signed-off-by: NJosef Bacik <josef@redhat.com>
      86d4a77b
  13. 04 6月, 2011 11 次提交
  15. 28 5月, 2011 1 次提交