search for: run_delalloc_rang

Hello I found that after defrag a file, the corresponding inode's i_blocks become incorrect. I hope following description address the real reason. i_blocks is decreased in 'btrfs_drop_extents' when something are drop/truncated and 'run_delalloc_range' calls 'btrfs_drop_extents' at first place, so 'run_delalloc_range' may decrease the i_blocks. ('btrfs_drop_extents' doesn't increase i_blocks). In normal write operation, i_blocks is increased in advance in 'dirty_and_release_pages', then decreased in ...

...43/0x5a vfs_stat+0x16/0x18 sys_newstat+0x3d/0x75 system_call_fastpath+0x16/0x1b And for file line fs/btrfs/inode.c 1378 btrfs_clear_bit_hook+0xcc1/0x10f2 clear_state_bit+0x4db/0xa89 clear_extent_bit+0x9e1/0xc86 extent_clear_unlock_delalloc+0x8c/0x1d8 cow_file_range+0x1356/0x1432 run_delalloc_range+0x263/0x1702 __extent_writepage+0x2c4/0x15a8 extent_write_cache_pages.clone.0+0x211/0x33d extent_writepages+0x243/0x260 btrfs_writepages+0x87/0x92 do_writepages+0x1c/0x25 writeback_single_inode+0xe2/0x24c writeback_inodes_wb+0x374/0x48d wb_writeback+0x121/0x1f6 wb_do_writeback+0x...

...0000000 0000394d 00000246 f7945c64 c041fec6 42a9fd92 00000172 027f9000 00000000 00000000 f7945d10 f8b9a246 027f9000 00000000 00000003 00000000 00000671 Call Trace: [<c041fec6>] ? hrtick_set+0xcf/0xd7 [<f8b9a246>] ? cow_file_range+0x15f/0x243 [btrfs] [<f8b9a89f>] ? run_delalloc_range+0x294/0x2b5 [btrfs] [<f8ba622b>] ? unlock_extent+0x17/0x19 [btrfs] [<f8ba69ed>] ? __extent_writepage+0x1a0/0x62d [btrfs] [<c0456f41>] ? write_cache_pages+0x180/0x287 [<f8ba684d>] ? __extent_writepage+0x0/0x62d [btrfs] [<f8b9b079>] ? btrfs_writepages+0x0/0x1d [btr...

...VED 4 #define BTRFS_INODE_HAS_ORPHAN_ITEM 5 +#define BTRFS_INODE_HAS_ASYNC_EXTENT 6 /* in memory btrfs inode */ struct btrfs_inode { diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 293c018..aef3054 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1398,20 +1398,23 @@ static int run_delalloc_range(struct inode *inode, struct page *locked_page, int ret; struct btrfs_root *root = BTRFS_I(inode)->root; - if (BTRFS_I(inode)->flags & BTRFS_INODE_NODATACOW) + if (BTRFS_I(inode)->flags & BTRFS_INODE_NODATACOW) { ret = run_delalloc_nocow(inode, locked_page, start, end,...

...26:06 rohan kernel: [ 3878.951105] [<ffffffffa0533120>] ? btrfs_tree_read_unlock_blocking+0x40/0x60 [btrfs] Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffffa050c8e7>] run_delalloc_nocow+0x397/0x7a0 [btrfs] Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffffa050cd47>] run_delalloc_range+0x57/0x80 [btrfs] Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffffa052303d>] __extent_writepage+0x5bd/0x700 [btrfs] Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffff8131443d>] ? radix_tree_gang_lookup_tag_slot+0x8d/0xd0 Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<...

I suspect this might be related to previous btrfs errors I''ve had on the same filesystem. See: http://python.ca/nas/linux/btrfs_bug.txt The most recent kernel message is: WARNING: at fs/btrfs/extent-tree.c:8239 btrfs_free_block_groups+0x218/0x275() Hardware name: MS-7388 Modules linked in: udf crc_itu_t isofs loop nls_iso8859_1 vboxnetflt vboxdrv nls_utf8 nls_cp437

...ff8801a1fb15f0 ffff88019d8bb800 ffff8801a09ad360 ffff8801a1fb18d4 [ 153.914485] Call Trace: [ 153.914516] [<ffffffffa01b687f>] ? free_extent_buffer+0x2f/0x70 [btrfs] [ 153.914565] [<ffffffffa0198173>] run_delalloc_nocow+0x3c3/0x950 [btrfs] [ 153.914615] [<ffffffffa0198a31>] run_delalloc_range+0x331/0x3a0 [btrfs] [ 153.914665] [<ffffffffa01b52f1>] __extent_writepage+0x341/0x7c0 [btrfs] [ 153.914715] [<ffffffffa01b5a52>] extent_write_cache_pages.isra.26.constprop.44+0x2e2/0x3e0 [btrfs] [ 153.914775] [<ffffffffa01b5da5>] extent_writepages+0x45/0x60 [btrfs] [ 153.9...

...Trace: [ 68.127508] [<ffffffffa0482f29>] ? release_extent_buffer+0xa9/0xd0 [btrfs] [ 68.127553] [<ffffffffa048862f>] ? free_extent_buffer+0x4f/0xa0 [btrfs] [ 68.127598] [<ffffffffa04716d6>] run_delalloc_nocow+0x436/0xaf0 [btrfs] [ 68.127641] [<ffffffffa0472180>] run_delalloc_range+0x320/0x390 [btrfs] [ 68.127685] [<ffffffffa04854c1>] ? find_lock_delalloc_range.constprop.44+0x1d1/0x1f0 [btrfs] [ 68.127735] [<ffffffffa0487044>] __extent_writepage+0x354/0x7b0 [btrfs] [ 68.127772] [<ffffffff81122645>] ? find_get_pages_tag+0x105/0x180 [ 68.127813] [...

The freeze rwsem is taken by sb_start_intwrite() and dropped during the commit_ or end_transaction(). In the async case, that happens in a worker thread. Tell lockdep the calling thread is releasing ownership of the rwsem and the async thread is picking it up. Josef and I worked out a more complicated solution that made the async commit thread join and potentially get a later transaction, but

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

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.

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103