https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4540 Lustre <p>This issue was created by maloo for Nathaniel Clark &lt;nathaniel.l.clark@intel.com&gt;</p> <p>This issue relates to the following test suite run: <a href="http://maloo.whamcloud.com/test_sets/ffb7e79e-83c2-11e3-bedf-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">http://maloo.whamcloud.com/test_sets/ffb7e79e-83c2-11e3-bedf-52540035b04c</a>.</p> <p>The sub-test test_8 failed with the following error:</p> <blockquote> <p>test failed to respond and timed out</p></blockquote> <p>Info required for matching: sanity-quota 8</p> <p>Client console:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>04:28:33:dbench D 0000000000000001 0 29279 29278 0x00000080 04:28:33: ffff88007cfd58e8 0000000000000082 00000002ffffffff 000061b9fbe152ee 04:28:33: ffffffffffffffff ffff880037c4f280 00000000015e9fd8 ffffffffad20e0cc 04:28:33: ffff8800668bbab8 ffff88007cfd5fd8 000000000000fb88 ffff8800668bbab8 04:28:33:Call Trace: 04:28:33: [&lt;ffffffff810a2431&gt;] ? ktime_get_ts+0xb1/0xf0 04:28:33: [&lt;ffffffff81119e10&gt;] ? sync_page+0x0/0x50 04:28:33: [&lt;ffffffff8150e953&gt;] io_schedule+0x73/0xc0 04:28:33: [&lt;ffffffff81119e4d&gt;] sync_page+0x3d/0x50 04:28:33: [&lt;ffffffff8150f30f&gt;] __wait_on_bit+0x5f/0x90 04:28:33: [&lt;ffffffff8111a083&gt;] wait_on_page_bit+0x73/0x80 04:28:33: [&lt;ffffffff81096de0&gt;] ? wake_bit_function+0x0/0x50 04:28:33: [&lt;ffffffffa1602c65&gt;] vvp_page_assume+0x35/0xa0 [lustre] 04:28:33: [&lt;ffffffffa0ffcc88&gt;] cl_page_invoid+0x68/0x160 [obdclass] 04:28:33: [&lt;ffffffffa0fff1a6&gt;] cl_page_assume+0x56/0x220 [obdclass] 04:28:33: [&lt;ffffffffa15f0a08&gt;] ll_write_begin+0xf8/0x740 [lustre] 04:28:33: [&lt;ffffffff8111a7b3&gt;] generic_file_buffered_write+0x123/0x2e0 04:28:33: [&lt;ffffffff81075887&gt;] ? current_fs_time+0x27/0x30 04:28:33: [&lt;ffffffff8111c210&gt;] __generic_file_aio_write+0x260/0x490 04:28:33: [&lt;ffffffffa0e7fa81&gt;] ? libcfs_debug_msg+0x41/0x50 [libcfs] 04:28:33: [&lt;ffffffff8111c4c8&gt;] generic_file_aio_write+0x88/0x100 04:28:33: [&lt;ffffffffa160652b&gt;] vvp_io_write_start+0xdb/0x3d0 [lustre] 04:28:33: [&lt;ffffffffa1007c9a&gt;] cl_io_start+0x6a/0x140 [obdclass] 04:28:33: [&lt;ffffffffa100bdf4&gt;] cl_io_loop+0xb4/0x1b0 [obdclass] 04:28:33: [&lt;ffffffffa15a5c96&gt;] ll_file_io_generic+0x2b6/0x710 [lustre] 04:28:33: [&lt;ffffffffa0ffbd69&gt;] ? cl_env_get+0x29/0x350 [obdclass] 04:28:33: [&lt;ffffffffa15a6962&gt;] ll_file_aio_write+0x142/0x2c0 [lustre] 04:28:33: [&lt;ffffffffa15a6c4c&gt;] ll_file_write+0x16c/0x2a0 [lustre] 04:28:33: [&lt;ffffffff81181398&gt;] vfs_write+0xb8/0x1a0 04:28:33: [&lt;ffffffff81181d52&gt;] sys_pwrite64+0x82/0xa0 04:28:33: [&lt;ffffffff8100b072&gt;] system_call_fastpath+0x16/0x1b </pre> </div></div> LU-4540

Test failure sanity-quota test_8: dbench hung in vvp_page_assume

Bug Blocker Resolved Fixed Jinshan Xiong Maloo MB Fri, 24 Jan 2014 19:06:17 +0000 Mon, 3 Mar 2014 14:16:13 +0000 Thu, 6 Feb 2014 07:12:28 +0000 Lustre 2.6.0 0 5 <p>This is probably related to lockups I see in my testing that Jinshan thinks were introduced with a stream of recent clio changes.</p> <p>I have a patch in testing that we'll upload somewhere once complete.</p> <p>patch is at: <a href="http://review.whamcloud.com/9036" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/9036</a></p> <p>patch landed</p> <p>The landed fix didn't make clear which change introduced the regression. Does someone have that handy?</p> <p>This issue was introduced by <a href="https://jira.whamcloud.com/browse/LU-3321" title="2.x single thread/process throughput degraded from 1.8" class="issue-link" data-issue-key="LU-3321"><del>LU-3321</del></a>. The writing thread is holding page lock of page A, and then wait for write back bit of page B; meanwhile ptlrpc thread is trying to send out a write request, so it set the write back bit of page B, and then trying to lock page A to set write back bit. This is a deadlock case.</p> <p>In the patch, the writing thread will check if the page has WriteBack bit set before trying to dirty again.</p> <p>Hi Jinshan,</p> <p>Do you think whether this problem can happen in other functions, e.g. ll_read_ahead_pages? ll_read_ahead_pages also calls cl_page_assume() when holding the lock of other pages.</p> <p>Thank you!</p> <p>Hi Li Xi,</p> <p>I don't think it can happen in ll_read_ahead_pages() because this problem is introduced by holding a page lock and waiting for another page. This is not the case for read ahead.</p> Duplicate LU-4561 Development Rank 1|hzwdl3: Rank (Obsolete) 12409 Severity