search for: __filemap_fdatawrite_range

...x0/0x2d Apr 11 10:13:29 server kernel: [<f885a661>] journal_stop+0x195/0x1ba [jbd] Apr 11 10:13:29 server kernel: [<c0495caa>] __writeback_single_inode+0x197/0x2a3 Apr 11 10:13:29 server kernel: [<c045ee18>] do_writepages+0x2b/0x32 Apr 11 10:13:29 server kernel: [<c045a96c>] __filemap_fdatawrite_range+0x66/0x72 Apr 11 10:13:29 server kernel: [<c0496346>] sync_inode+0x19/0x24 Apr 11 10:13:29 server kernel: [<f8983009>] ext3_sync_file+0xb1/0xdc [ext3] Apr 11 10:13:29 server kernel: [<c047956c>] do_fsync+0x41/0x83 Apr 11 10:13:29 server kernel: [<c04795cb>] __do_fsync+0x1d/0...

...t4_io_submit+0x44/0x50 [ 2504.247556] ext4_writepages+0x621/0xe80 [ 2504.248028] ? 0xffffffff81000000 [ 2504.248418] ? do_writepages+0x46/0xd0 [ 2504.248880] ? ext4_mark_inode_dirty+0x1d0/0x1d0 [ 2504.249417] do_writepages+0x46/0xd0 [ 2504.249833] ? release_pages+0x175/0x390 [ 2504.250290] ? __filemap_fdatawrite_range+0x7c/0xb0 [ 2504.250879] __filemap_fdatawrite_range+0x7c/0xb0 [ 2504.251427] ext4_release_file+0x67/0xa0 [ 2504.251897] __fput+0xb1/0x220 [ 2504.252260] task_work_run+0x79/0xa0 [ 2504.252676] do_exit+0x2ca/0xc10 [ 2504.253063] ? __switch_to_asm+0x40/0x70 [ 2504.253530] ? __switch_to_asm+0x34...

...t4_io_submit+0x44/0x50 [ 2504.247556] ext4_writepages+0x621/0xe80 [ 2504.248028] ? 0xffffffff81000000 [ 2504.248418] ? do_writepages+0x46/0xd0 [ 2504.248880] ? ext4_mark_inode_dirty+0x1d0/0x1d0 [ 2504.249417] do_writepages+0x46/0xd0 [ 2504.249833] ? release_pages+0x175/0x390 [ 2504.250290] ? __filemap_fdatawrite_range+0x7c/0xb0 [ 2504.250879] __filemap_fdatawrite_range+0x7c/0xb0 [ 2504.251427] ext4_release_file+0x67/0xa0 [ 2504.251897] __fput+0xb1/0x220 [ 2504.252260] task_work_run+0x79/0xa0 [ 2504.252676] do_exit+0x2ca/0xc10 [ 2504.253063] ? __switch_to_asm+0x40/0x70 [ 2504.253530] ? __switch_to_asm+0x34...

...rite+0x1a9/0x900 [btrfs] [ 899.119222] [<c019cb7a>] open_namei+0x8a/0x640 [ 899.119244] [<c018ffa5>] nameidata_to_filp+0x35/0x40 [ 899.119255] [<c018fa90>] generic_file_open+0x0/0x60 [ 899.119265] [<c0190000>] do_filp_open+0x50/0x60 [ 899.119277] [<c016e56a>] __filemap_fdatawrite_range+0x7a/0xa0 [ 899.119300] [<f90f44e0>] btrfs_file_write+0x0/0x900 [btrfs] [ 899.119341] [<c01921b9>] vfs_write+0xb9/0x170 [ 899.119356] [<c01928f1>] sys_write+0x41/0x70 [ 899.119375] [<c01043c2>] sysenter_past_esp+0x6b/0xa9 [ 899.119388] ======================= [ 89...

...247556] ext4_writepages+0x621/0xe80 > [ 2504.248028] ? 0xffffffff81000000 > [ 2504.248418] ? do_writepages+0x46/0xd0 > [ 2504.248880] ? ext4_mark_inode_dirty+0x1d0/0x1d0 > [ 2504.249417] do_writepages+0x46/0xd0 > [ 2504.249833] ? release_pages+0x175/0x390 > [ 2504.250290] ? __filemap_fdatawrite_range+0x7c/0xb0 > [ 2504.250879] __filemap_fdatawrite_range+0x7c/0xb0 > [ 2504.251427] ext4_release_file+0x67/0xa0 > [ 2504.251897] __fput+0xb1/0x220 > [ 2504.252260] task_work_run+0x79/0xa0 > [ 2504.252676] do_exit+0x2ca/0xc10 > [ 2504.253063] ? __switch_to_asm+0x40/0x70 > [ 2...

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

...fs] [<ffffffffa0340d22>] extent_write_cache_pages.isra.26.constprop.40+0x2b2/0x410 [btrfs] [<ffffffffa03410c5>] extent_writepages+0x45/0x60 [btrfs] [<ffffffffa0327178>] btrfs_writepages+0x28/0x30 [btrfs] [<ffffffff81122b21>] do_writepages+0x21/0x40 [<ffffffff81118e5b>] __filemap_fdatawrite_range+0x5b/0x60 [<ffffffff8111982c>] filemap_flush+0x1c/0x20 [<ffffffffa0334289>] btrfs_start_delalloc_inodes+0xc9/0x1f0 [btrfs] [<ffffffffa0324f5d>] btrfs_commit_transaction+0x44d/0xaf0 [btrfs] [<ffffffffa035200d>] btrfs_mksubvol.isra.53+0x37d/0x440 [btrfs] [<ffffffffa03521ca&...

...t+0x1ce/0x3f0 [btrfs] Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffffa0506ff8>] btrfs_writepages+0x28/0x30 [btrfs] Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffff811245c1>] do_writepages+0x21/0x40 Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffff8111a8bb>] __filemap_fdatawrite_range+0x5b/0x60 Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffff8111b2af>] filemap_fdatawrite+0x1f/0x30 Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffff8111b2f5>] filemap_write_and_wait+0x35/0x60 Aug 4 02:26:06 rohan kernel: [ 3878.951105] [<ffffffffa053ad2f>] __btrfs_...

...fs_writepage+0x70/0x70 [btrfs] [ 153.914871] [<ffffffffa01b191e>] ? free_extent_state+0x1e/0x30 [btrfs] [ 153.914919] [<ffffffffa0193338>] btrfs_writepages+0x28/0x30 [btrfs] [ 153.916201] [<ffffffff81118082>] do_writepages+0x22/0x50 [ 153.916315] [<ffffffff8110d5fb>] __filemap_fdatawrite_range+0x5b/0x60 [ 153.916315] [<ffffffff8110d61f>] filemap_fdatawrite+0x1f/0x30 [ 153.920013] [<ffffffff8110d665>] filemap_write_and_wait+0x35/0x60 [ 153.920013] [<ffffffffa01cf622>] __btrfs_write_out_cache+0x792/0x9a0 [btrfs] [ 153.920013] [<ffffffffa0175b25>] ? __find_sp...

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

...writepages+0x4d/0x70 [btrfs] [ 68.127909] [<ffffffffa046e080>] ? can_nocow_odirect+0x2f0/0x2f0 [btrfs] [ 68.127951] [<ffffffffa046cf28>] btrfs_writepages+0x28/0x30 [btrfs] [ 68.127985] [<ffffffff8112e28e>] do_writepages+0x1e/0x40 [ 68.128014] [<ffffffff81123669>] __filemap_fdatawrite_range+0x59/0x60 [ 68.128048] [<ffffffff81123733>] filemap_fdatawrite_range+0x13/0x20 [ 68.128090] [<ffffffffa0481c99>] btrfs_wait_ordered_range+0x49/0x110 [btrfs] [ 68.128135] [<ffffffffa04a64c0>] __btrfs_write_out_cache+0x6d0/0x8f0 [btrfs] [ 68.128180] [<ffffffffa04a774d...

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

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