search for: btrfs_run_ordered_operations

...fs_trans_handle *trans, unsigned long now = get_seconds(); int flush_on_commit = btrfs_test_opt(root, FLUSHONCOMMIT); + /* + * Since some error may force btrfs readonly, this can + * avoid backgroud writeback. + */ + if (root->fs_info->sb->s_flags & MS_RDONLY) + return 0; + btrfs_run_ordered_operations(root, 0); /* make a pass through all the delayed refs we have so far -- 1.7.0.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.html

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 in commit path via

Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the

Hi I am hitting this Warning reproducible, the workload is a ceph osd, kernel ist 3.1.0-rc5. Best Regards, martin [ 5472.099766] ------------[ cut here ]------------ [ 5472.099833] WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]() [ 5472.099838] Hardware name: MS-96B3 [ 5472.099842] Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit psmouse sp5100_tco

...nel: [<f898bb06>] run_clustered_refs+0x626/0x8c0 [btrfs] Oct 8 02:40:52 (none) kernel: [<f89d4c01>] ? btrfs_find_ref_cluster+0x1/0x1a0 [btrfs] Oct 8 02:40:52 (none) kernel: [<f898be47>] btrfs_run_delayed_refs+0xa7/0x1c0 [btrfs] Oct 8 02:40:52 (none) kernel: [<f89b706b>] ? btrfs_run_ordered_operations+0x1db/0x1f0 [btrfs] Oct 8 02:40:52 (none) kernel: [<f89996f4>] btrfs_commit_transaction+0x64/0x6f0 [btrfs] Oct 8 02:40:52 (none) kernel: [<c105eb30>] ? autoremove_wake_function+0x0/0x40 Oct 8 02:40:52 (none) kernel: [<f899443f>] transaction_kthread+0x20f/0x230 [btrfs] Oct 8 02...

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

..._ordered_sum(struct inode *inode, + struct btrfs_ordered_extent *entry, + struct btrfs_ordered_sum *sum); struct btrfs_ordered_extent *btrfs_lookup_ordered_extent(struct inode *inode, u64 file_offset); void btrfs_start_ordered_extent(struct inode *inode, @@ -174,6 +174,6 @@ int btrfs_run_ordered_operations(struct btrfs_root *root, int wait); int btrfs_add_ordered_operation(struct btrfs_trans_handle *trans, struct btrfs_root *root, struct inode *inode); -int btrfs_wait_ordered_extents(struct btrfs_root *root, - int nocow_only, int delay_iput); +void btrfs_wait_ordered_extents(struc...

...s and I get "INFO: task btrfs-transacti:1698 blocked for more than 120 seconds." messages reporting the thread to be stuck in [<ffffffff816c671d>] wait_for_completion+0x1d/0x20 [<ffffffffa01d9b76>] btrfs_wait_and_free_delalloc_work+0x16/0x30 [btrfs] [<ffffffffa01e1590>] btrfs_run_ordered_operations+0x290/0x2f0 [btrfs] [<ffffffffa01ca7af>] btrfs_commit_transaction+0x5f/0xab0 [btrfs] [<ffffffffa01c3cfd>] transaction_kthread+0x1bd/0x240 [btrfs] [ 2040.620221] [<ffffffff8107d290>] kthread+0xc0/0xd0 but that seems harmless otherwise. The system seems slow but usable after this,...

..._refs+0x132/0x830 [btrfs] May 5 14:15:14 mail kernel: [13560.752105] [<ffffffff813aff3d>] schedule_timeout+0x2fd/0x380 May 5 14:15:14 mail kernel: [13560.752108] [<ffffffff813b0cf9>] ? mutex_unlock+0x9/0x10 May 5 14:15:14 mail kernel: [13560.752115] [<ffffffffa087e9f4>] ? btrfs_run_ordered_operations+0x1f4/0x210 [btrfs] May 5 14:15:14 mail kernel: [13560.752122] [<ffffffffa0860fa3>] btrfs_commit_transaction+0x263/0x750 [btrfs] May 5 14:15:14 mail kernel: [13560.752126] [<ffffffff81079ff0>] ? autoremove_wake_function+0x0/0x40 May 5 14:15:14 mail kernel: [13560.752131] [<ff...

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.