search for: extent_commit_sem

caching_thread()s do all their work under read access to extent_commit_sem. They give up on this read access only when need_resched() tells them, or when they exit. As a result, somebody that wants a WRITE access to this sem, might wait for a long time. Especially this is problematic in cache_block_group(), which can be called on critical paths like find_free_extent() and...

...t we need to make sure that the orphan + * cleanup has been done and committed since we search the commit root, + * so check its commit root transid with our otransid and if they match + * commit the transaction to make sure everything is updated. + */ + down_read(&send_root->fs_info->extent_commit_sem); + if (btrfs_header_generation(send_root->commit_root) == + btrfs_root_otransid(&send_root->root_item)) { + struct btrfs_trans_handle *trans; + + up_read(&send_root->fs_info->extent_commit_sem); + + trans = btrfs_attach_transaction_barrier(send_root); + if (IS_ERR(trans...

...--------------- 5 files changed, 55 insertions(+), 36 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index f6ad2d5..ec7884c 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -859,8 +859,9 @@ struct btrfs_fs_info { struct mutex ordered_operations_mutex; struct rw_semaphore extent_commit_sem; - struct rw_semaphore subvol_sem; + struct rw_semaphore cleanup_work_sem; + struct rw_semaphore subvol_sem; struct srcu_struct subvol_srcu; struct list_head trans_list; @@ -1034,12 +1035,12 @@ struct btrfs_root { int ref_cows; int track_dirty; int in_radix; + int clean_orphans;...

worker_loop() uses schedule_timeout() without setting state to STATE_(UN)INTERRUPTIBLE. As it is called in cycle without checking of pending signals, use schedule_timeout_uninterruptible(). Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> --- fs/btrfs/async-thread.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c

If we have particularly full nodes, we could call btrfs_node_blockptr up to 32 times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the extent buffer while we look for readahead targets. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git

First two patches are trivial cleanups that I''ve spotted while reading send.c, can be applied independently. The third patch contains the important bits, safety checks that the subvolumes involved in send do not accidentally lose the RO status. I haven''t seen this documented anywhere that this is mandatory, implied from how I assume send works. Please let me know if this is

...; + WARN_ON(fs_info->chunk_block_rsv.reserved > 0); } static u64 calc_trans_metadata_size(struct btrfs_root *root, int num_items) @@ -3694,6 +3801,8 @@ int btrfs_prepare_extent_commit(struct b fs_info->pinned_extents = &fs_info->freed_extents[0]; up_write(&fs_info->extent_commit_sem); + + update_global_block_rsv(fs_info); return 0; } @@ -4682,19 +4791,16 @@ static void dump_space_info(struct btrfs printk(KERN_INFO "space_info has %llu free, is %sfull\n", (unsigned long long)(info->total_bytes - info->bytes_used - info->bytes_pinned -...

Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them