search for: join_transaction

...iff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 02ff4a1..4e9aa28 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3646,7 +3646,7 @@ void btrfs_evict_inode(struct inode *inode) btrfs_i_size_write(inode, 0); while (1) { - trans = btrfs_start_transaction(root, 0); + trans = btrfs_join_transaction(root); BUG_ON(IS_ERR(trans)); trans->block_rsv = root->orphan_block_rsv; -- 1.7.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info....

...<ffffffffa032d201>] ? btrfs_find_ref_cluster+0xd/0x13c [btrfs] [<ffffffffa02e9fd6>] ? btrfs_run_delayed_refs+0xd1/0x17c [btrfs] [<ffffffffa02f8467>] ? btrfs_commit_transaction+0x38f/0x709 [btrfs] [<ffffffff8136f6e6>] ? _raw_spin_lock+0xe/0x10 [<ffffffffa02f79fe>] ? join_transaction.clone.23+0xc1/0x200 [btrfs] [<ffffffff81068ffb>] ? wake_up_bit+0x2a/0x2a [<ffffffffa02f28fd>] ? transaction_kthread+0x175/0x22a [btrfs] [<ffffffffa02f2788>] ? btrfs_congested_fn+0x86/0x86 [btrfs] [<ffffffff81068b2c>] ? kthread+0x82/0x8a [<ffffffff81376124>] ? kern...

If we flush inodes with pending delalloc in a transaction, we may join the same transaction handler more than 2 times. The reason is: Task use_count of trans handle commit_transaction 1 |-> btrfs_start_delalloc_inodes 1 |-> run_delalloc_nocow 1 |-> join_transaction 2 |-> cow_file_range 2 |-> join_transaction 3 In fact, cow_file_range needn''t join the transaction again because the caller have joined the transaction, so we fix this problem by this way. Reported-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Miao Xie <miaox@cn....

...t; 0) goto out; diff -urNp linux-2.6.38/fs/btrfs/transaction.c linux-2.6.38.new/fs/btrfs/transaction.c --- linux-2.6.38/fs/btrfs/transaction.c 2011-03-15 10:20:32.000000000 +0900 +++ linux-2.6.38.new/fs/btrfs/transaction.c 2011-03-23 11:28:09.000000000 +0900 @@ -57,7 +57,8 @@ static noinline int join_transaction(str if (!cur_trans) { cur_trans = kmem_cache_alloc(btrfs_transaction_cachep, GFP_NOFS); - BUG_ON(!cur_trans); + if (!cur_trans) + return -ENOMEM; root->fs_info->generation++; cur_trans->num_writers = 1; cur_trans->num_joined = 0; @@ -195,7 +196,11 @@ again:...

...t_del_init(&transaction->list); + radix_tree_delete(&root->fs_info->transaction_map_radix, + (unsigned long)transaction->transid); memset(transaction, 0, sizeof(*transaction)); kmem_cache_free(btrfs_transaction_cachep, transaction); } @@ -49,13 +52,15 @@ static int join_transaction(struct btrfs struct btrfs_transaction *cur_trans; cur_trans = root->fs_info->running_transaction; if (!cur_trans) { + int ret; cur_trans = kmem_cache_alloc(btrfs_transaction_cachep, GFP_NOFS); total_trans++; BUG_ON(!cur_trans); root->fs_info->generation++;...

...000000000001 ffff8800b4b378b8 ffff88011198dd08 ffff88011263fe80 ffff8801046a7400 ffff880105618540 ffff88011198dd78 ffff88011263fef8 Call Trace: [<ffffffff811b469e>] write_ctree_super+0xe/0x10 [<ffffffff811b9778>] btrfs_commit_transaction+0x6a8/0x870 [<ffffffff811b8a8a>] ? join_transaction+0x24a/0x280 [<ffffffff810611f0>] ? wake_up_bit+0x40/0x40 [<ffffffff81195a57>] btrfs_sync_fs+0x47/0x70 [<ffffffff811029be>] __sync_filesystem+0x5e/0x90 [<ffffffff81102a53>] sync_filesystem+0x43/0x60 [<ffffffff810dc226>] generic_shutdown_super+0x36/0xe0 [<...

...en we pass 80% used in the metadata space. Also, instead of doing a trans = btrfs_start_transaction(root, 1); btrfs_commit_transaction(trans, root); You will want to do btrfs_force_transacation_commit(root, 0); This does not do any of the free space checks that btrfs_start_transaction or btrfs_join_transaction does, since we expect to _only_ be committing the transaction. This makes sure that we use the reserved space for committing the transaction and don''t end up with ENOSPC being returned to the transaction kthread. This has been hammered on pretty well with various tests and seems to work...

...l: [870100.614281] [<ffffffffa01bb32e>] ? btrfs_run_delayed_refs+0x237/0x394 [btrfs] Jun 25 17:02:25 hsad-srv-03 kernel: [870100.614296] [<ffffffffa01c82ff>] ? btrfs_commit_transaction+0xaf/0x87a [btrfs] Jun 25 17:02:25 hsad-srv-03 kernel: [870100.614310] [<ffffffffa01c7365>] ? join_transaction.isra.29+0x314/0x31e [btrfs] Jun 25 17:02:25 hsad-srv-03 kernel: [870100.614314] [<ffffffff8105866b>] ? abort_exclusive_wait+0x79/0x79 Jun 25 17:02:25 hsad-srv-03 kernel: [870100.614329] [<ffffffffa01c92cc>] ? start_transaction+0x325/0x44d [btrfs] Jun 25 17:02:25 hsad-srv-03 kernel: [8...

...ndir kernel: [40871.705822] [<ffffffffa0d77e38>] btrfs_run_delayed_refs+0xcc/0x17c [btrfs] Jun 10 14:50:23 mithrandir kernel: [40871.705871] [<ffffffffa0d85775>] btrfs_commit_transaction+0x72/0x655 [btrfs] Jun 10 14:50:23 mithrandir kernel: [40871.705920] [<ffffffffa0d84d89>] ? join_transaction.isra.23+0x203/0x20a [btrfs] Jun 10 14:50:23 mithrandir kernel: [40871.705964] [<ffffffff810481d4>] ? add_wait_queue+0x44/0x44 Jun 10 14:50:23 mithrandir kernel: [40871.706006] [<ffffffffa0d80180>] transaction_kthread+0x174/0x22b [btrfs] Jun 10 14:50:23 mithrandir kernel: [40871.706053...

I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last

Hello, I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using the 3.1 kernel, I found a patch for these warnings ( http://marc.info/?l=linux-btrfs&m=131547325515336&w=2) <http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch has already been included in 3.1. Are there any other patches I can try? I''m using

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

...t > 0) return -ENOENT; - BUG_ON(ret); + btrfs_fixable_bug_on(ret); generation = btrfs_root_generation(&root->root_item); blocksize = btrfs_level_size(root, btrfs_root_level(&root->root_item)); @@ -1501,7 +1501,7 @@ static int transaction_kthread(void *arg) trans = btrfs_join_transaction(root, 1); if (transid == trans->transid) { ret = btrfs_commit_transaction(trans, root); - BUG_ON(ret); + btrfs_fixable_bug_on(ret); } else { btrfs_end_transaction(trans, root); } @@ -1954,20 +1954,20 @@ struct btrfs_root *open_ctree(struct super_block *sb, block...

From: Anand Jain <anand.jain@oracle.com> (This patch is for the review/test not yet for the integration). Here is an implementation of the feature to add label to the subvolume and snapshots. Which would help sysadmin to better manager the subvol and snapshots. This can be done in two ways, one - using attr which is user land only changes but drawback is able to change the label

This is a first draft of a subvolume quota implementation. It is possible to limit subvolumes and any group of subvolumes and also to track the amount of space that will get freed when deleting snapshots. The current version is functionally incomplete, with the main missing feature being the initial scan and rescan of an existing filesystem. I put some effort into writing an introduction into