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-9868 Lustre <p>From Neil Brown that works at SuSE</p> <p>I was drawn to look at this code due to the tests on<br/> DCACHE_DISCONNECTED which are often wrong, and it turns out<br/> they are used wrongly in lustre too. Fixing one led to some<br/> clean-up. Fixing the other is straight forward.</p> <p>A particular change here from the previous posting is<br/> the first patch which tests for DCACHE_PAR_LOOKUP in ll_dcompare().<br/> Without this patch, two threads can be looking up the same<br/> name in a given directory in parallel. This parallelism lead<br/> to my concerns about needing improved locking in ll_splice_alias().<br/> Instead of improving the locking, I now avoid the need for it<br/> by fixing ll_dcompare.</p> <p>This code passes basic "smoke tests".</p> <p>Note that the cast to "struct dentry *" in the first patch is because<br/> we have a "const struct dentry *" but d_in_lookup() requires a<br/> pointer to a non-const structure. I'll send a separate patch to<br/> change d_in_lookup().</p> upstream and well as any lustre 2.11 client. LU-9868

dcache/namei fixes for lustre

Bug Major Open Unresolved James A Simmons James A Simmons patch upstream Fri, 11 Aug 2017 17:02:54 +0000 Thu, 24 Nov 2022 14:32:32 +0000 Upstream Lustre 2.11.0 Lustre 2.12.0 Lustre 2.10.5 Upstream 0 13 <p>James Simmons (uja.ornl@yahoo.com) uploaded a new patch: <a href="https://review.whamcloud.com/28486" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/28486</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: dcache/namei fixes for lustre<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: ee439ac5304343708bc344c62297749c5909d59e</p> <p>I gave it a spin, but opening a file under vim (probably a mix of stat/open/write/chmod operations) hangs the process. Trace is :</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> Sep 28 17:50:46 p0851 kernel: INFO: rcu_sched self-detected stall on CPU { 7} (t=60000 jiffies g=16256 c=16255 q=13733) Sep 28 17:50:46 p0851 kernel: Task dump <span class="code-keyword">for</span> CPU 7: Sep 28 17:50:46 p0851 kernel: vim R running task 0 28301 28299 0x0000000b Sep 28 17:50:46 p0851 kernel: Call Trace: Sep 28 17:50:46 p0851 kernel: &lt;IRQ&gt; [&lt;ffffffffa6ed1268&gt;] sched_show_task+0xa8/0x110 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6ed4e39&gt;] dump_cpu_task+0x39/0x70 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6f4bb00&gt;] rcu_dump_cpu_stacks+0x90/0xd0 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6f4f1a2&gt;] rcu_check_callbacks+0x442/0x730 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6f046c0&gt;] ? tick_sched_do_timer+0x50/0x50 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6ea7a16&gt;] update_process_times+0x46/0x80 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6f044c0&gt;] tick_sched_handle+0x30/0x70 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6f046f9&gt;] tick_sched_timer+0x39/0x80 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6ec2163&gt;] __hrtimer_run_queues+0xf3/0x270 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6ec26ef&gt;] hrtimer_interrupt+0xaf/0x1d0 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6e596ab&gt;] local_apic_timer_interrupt+0x3b/0x60 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa752a083&gt;] smp_apic_timer_interrupt+0x43/0x60 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa75267b2&gt;] apic_timer_interrupt+0x162/0x170 Sep 28 17:50:46 p0851 kernel: &lt;EOI&gt; [&lt;ffffffffa6f0bb43&gt;] ? native_queued_spin_lock_slowpath+0x1d3/0x200 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa750dc5f&gt;] queued_spin_lock_slowpath+0xb/0xf Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa751b750&gt;] _raw_spin_lock+0x20/0x30 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa703bf3e&gt;] igrab+0x1e/0x60 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc1026040&gt;] ll_inode_from_resource_lock+0xa0/0xb0 [lustre] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc103ed92&gt;] ll_md_blocking_ast+0x52/0x730 [lustre] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6f9f8e4&gt;] ? free_one_page+0x2e4/0x310 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0e1321a&gt;] ldlm_cancel_callback+0x8a/0x330 [ptlrpc] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0e81f22&gt;] ? null_free_repbuf+0xd2/0x200 [ptlrpc] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6fa01fd&gt;] ? __free_pages+0x1d/0x30 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa6fa0412&gt;] ? __free_memcg_kmem_pages+0x22/0x50 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0e1e9b0&gt;] ldlm_cli_cancel_local+0xa0/0x420 [ptlrpc] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0e2303a&gt;] ldlm_cli_cancel_list_local+0xea/0x280 [ptlrpc] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0e2335b&gt;] ldlm_cancel_resource_local+0x18b/0x280 [ptlrpc] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0a93e92&gt;] mdc_resource_get_unused+0x142/0x2a0 [mdc] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0a94217&gt;] mdc_setattr+0x227/0x4a0 [mdc] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa7037779&gt;] ? dput+0x29/0x160 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc0f5ff54&gt;] lmv_setattr+0x1c4/0x570 [lmv] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc103115b&gt;] ll_setattr_raw+0x28b/0x1350 [lustre] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffc103228c&gt;] ll_setattr+0x6c/0xd0 [lustre] Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa703dc54&gt;] notify_change+0x2c4/0x420 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa701c837&gt;] chmod_common+0x137/0x160 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa701dac7&gt;] SyS_fchmodat+0x57/0xc0 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa701db49&gt;] SyS_chmod+0x19/0x20 Sep 28 17:50:46 p0851 kernel: [&lt;ffffffffa7525a1b&gt;] tracesys+0xa3/0xc9 </pre> </div></div> <p>Tested on Centos 7.5 3.10.0-862.14.4.el7.x86_64 kernel and Lustre 2.10.5.</p> <p>Yeah the original patch was based on a earlier version posted for upstream. A later patch set was done and landed. I just did a push of the new patch. My testing shows its in much better shape.</p> <p>Sorry about the breakage.</p> <p>We moved patchset 17 into production after some initial testing and as for now it has been running for over 3000 node days without any problems. Is there any plan to have the patchset included in b2_10 or master?</p> <p>Wow, that is awesome news. Before your report of fixing an actually production system their wasn't really a push to merge this for 2.12. Now it looks like it's an important fix for production systems.</p> <p>The way it works is that we have to port patches exactly from upstream to opensfs so we are looking at 5 patches instead of the one test patch I have currently. Since this fixes real problems I will push to 2.10.X once it lands to latest lustre.</p> <p><del>James Simmons (uja.ornl@yahoo.com) uploaded a new patch:</del> <a href="https://review.whamcloud.com/33258" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33258</a><br/> <del>Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: use d_splice_alias for directories.</del><br/> <del>Project: fs/lustre-release</del><br/> <del>Branch: master</del><br/> <del>Current Patch Set: 1</del><br/> <del>Commit: 025cf259d4a66b2a5de57a66891cb88f0e860e14</del></p> <p>James Simmons (uja.ornl@yahoo.com) uploaded a new patch: <a href="https://review.whamcloud.com/33259" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33259</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: remove directory-specific code from ll_find_alias()<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 58df6511f22d17a7cbe6d8d0f13d3c6da198c060</p> <p>James Simmons (uja.ornl@yahoo.com) uploaded a new patch: <a href="https://review.whamcloud.com/33260" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33260</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: simplify ll_find_alias()<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 808f713c96423555d57f11dd69d0a372cc30c769</p> <p>James Simmons (uja.ornl@yahoo.com) uploaded a new patch: <a href="https://review.whamcloud.com/33261" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33261</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: refine ll_find_alias based on d_exact_alias<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 160ed51460d9ab7be92a7abf4581560f9d97093a</p> <p>I see while this bug fixes things in newer kernel it breaks ancients kernel like RHEL.</p> <p>I found a work around to the bug the breaks older kernels. I'm testing it now.</p> <p>We think that any changes in this area would need to soak a while and get tested broadly before including into a release</p> <p>I agree. This is a complex problem so caution is required here.</p> <p>We are running <a href="https://review.whamcloud.com/#/c/28486" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/28486</a> - patch set 17 with b2_10 and as Marek said there were no major issues except few nodes with processes blocked in rename operation invoked by software called OOMMF. We are not sure it's related but i thought it's worth reporting</p> <p>Stacktrace:</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> [455219.524004] oxs D ffff984d68ba1fa0 0 3818 3806 0x00000000 [455219.558389] Call Trace: [455219.571231] [&lt;ffffffffa3f19e59&gt;] schedule_preempt_disabled+0x29/0x70 [455219.602131] [&lt;ffffffffa3f17c17&gt;] __mutex_lock_slowpath+0xc7/0x1d0 [455219.631887] [&lt;ffffffffa3f16fff&gt;] mutex_lock+0x1f/0x2f [455219.656923] [&lt;ffffffffa3a2b50a&gt;] lock_rename+0xda/0xe0 [455219.681973] [&lt;ffffffffa3a315bf&gt;] SYSC_renameat2+0x22f/0x5a0 [455219.709742] [&lt;ffffffffa39caefd&gt;] ? handle_mm_fault+0x39d/0x9b0 [455219.739183] [&lt;ffffffffa3f2056c&gt;] ? __do_page_fault+0x1bc/0x4f0 [455219.767746] [&lt;ffffffffa3a327ae&gt;] SyS_renameat2+0xe/0x10 [455219.793358] [&lt;ffffffffa3a327ee&gt;] SyS_rename+0x1e/0x20 [455219.818174] [&lt;ffffffffa3f2579b&gt;] system_call_fastpath+0x22/0x27 </pre> </div></div> <p>According to our logs issue has started to appear few days after deployment of client patched with <a href="https://review.whamcloud.com/#/c/28486" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/28486</a> - patch set 17</p> <p>I have noticed that current patch set is 22 - do you recommend to give upgrade a try ?</p> <p> </p> <p>UPDATE#1: or is it better way to patch rhel kernel like  SuSe did to address the issues now?</p> <p> </p> <p>I broke the patch up so its more than one now. Also a bug in lustre was exposed while testing this fix. On newer kernels it reports an error but older ones it will crash the node. Once I figure everything out I will port a 2.10 backported patch. The rename issue is new.</p> <p>OK. If so we will revert patch 17 from <a href="https://review.whamcloud.com/#/c/28486" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/28486</a> and see if the rename issue is gone as OOMMF crash is easily reproducible (however we don't have a separate reproducer yet). <br/> We'll update the ticket to make clear whether it's related</p> <p>Reverting patch 17 from <a href="https://review.whamcloud.com/#/c/28486" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/28486</a>  <b>fixed the problem</b> with clients hanging on rename in oommf</p> <p>We have four processes interacting, probably one is handling file writes, then signals another one which does rename opearations which lead to client lock-up after several dozens of such operations</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> [pid 5643] futex(0x2b774caf1d20, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 5643] sendto(17, <span class="code-quote">"reply 1762 0 0\r\n"</span>, 16, 0, NULL, 0) = 16 [pid 5643] recvfrom(18, <span class="code-quote">"query 13 datafile {/net/scratch/"</span>..., 4096, 0, NULL, NULL) = 305 [pid 5643] stat(<span class="code-quote">"/net/scratch/people/plgczuchr/OOMMF/dwieBariery/./dwieBariery/freeAniz_20000_Voltage_0.1500_mtop_-1_mfree_1_mbottom_1_VProfileType_0_/dwieBariery-Oxs_TimeDriver-Magnetization-00-0044000.omf"</span>, {st_mode=S_IFREG|0644, st_size=388216, ...}) = 0 [pid 5643] lstat(<span class="code-quote">"/net/scratch/people/plgczuchr/slurm_jobdir/13738101/tmp/dwieBariery-p1311.prometheus-5582.omf"</span>, {st_mode=S_IFREG|0644, st_size=388216, ...}) = 0 [pid 5643] lstat(<span class="code-quote">"/net/scratch/people/plgczuchr/OOMMF/dwieBariery/./dwieBariery/freeAniz_20000_Voltage_0.1500_mtop_-1_mfree_1_mbottom_1_VProfileType_0_/dwieBariery-Oxs_TimeDriver-Magnetization-00-0044000.omf"</span>, {st_mode=S_IFREG|0644, st_size=388216, ...}) = 0 [pid 5643] stat(<span class="code-quote">"/net/scratch/people/plgczuchr/OOMMF/dwieBariery/./dwieBariery/freeAniz_20000_Voltage_0.1500_mtop_-1_mfree_1_mbottom_1_VProfileType_0_/dwieBariery-Oxs_TimeDriver-Magnetization-00-0044000.omf"</span>, {st_mode=S_IFREG|0644, st_size=388216, ...}) = 0 [pid 5643] chmod(<span class="code-quote">"/net/scratch/people/plgczuchr/OOMMF/dwieBariery/./dwieBariery/freeAniz_20000_Voltage_0.1500_mtop_-1_mfree_1_mbottom_1_VProfileType_0_/dwieBariery-Oxs_TimeDriver-Magnetization-00-0044000.omf"</span>, 0644) = 0 [pid 5643] rename(<span class="code-quote">"/net/scratch/people/plgczuchr/slurm_jobdir/13738101/tmp/dwieBariery-p1311.prometheus-5582.omf"</span>, <span class="code-quote">"/net/scratch/people/plgczuchr/OOMMF/dwieBariery/./dwieBariery/freeAniz_20000_Voltage_0.1500_mtop_-1_mfree_1_mbottom_1_VProfileType_0_/dwieBariery-Oxs_TimeDriver-Magnetization-00-0044000.omf"</span>) = 0 [pid 5643] write(9, <span class="code-quote">"\0"</span>, 1 &lt;unfinished ...&gt; [pid 5652] &lt;... select resumed&gt; ) = 1 (in [8]) [pid 5643] &lt;... write resumed&gt; ) = 1 </pre> </div></div> <p>Thank you for this info and also for testing out this work. I will talk with Neil about this problem to see if we can resolve it.</p> <p>Which version of lustre are you running and is it only patched with <a href="https://review.whamcloud.com/#/c/28486/17" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/28486/17</a> ? Better yet can you</p> <p>share your rpms with us.</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/28486/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/28486/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: handle DCACHE_PAR_LOOKUP in ll_dcompare<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 32e547aa9cb913f5736ee3d58cb79f4e63ce2c0b</p> <p>Sebastien Piechurski (sebastien.piechurski@atos.net) uploaded a new patch: <a href="https://review.whamcloud.com/34582" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34582</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: handle DCACHE_PAR_LOOKUP in ll_dcompare<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: fb6aa13622d441b3495287cbc2630cc47da7c4ae</p> <p>Any chances to have the patch included in 2.12.1 ?</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=spiechurski" class="user-hover" rel="spiechurski">spiechurski</a> it would be possible but what is the driver to do so?</p> <p>Note the work is not complete. I need to solve the dcache hard link breakage issue. I have an idea on how to fix it but it will take some time to resolve it.</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=pjones" class="user-hover" rel="pjones">pjones</a> : one of our customer (Cardiff University) is hitting this issue from time to time.</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=simmonsja" class="user-hover" rel="simmonsja">simmonsja</a> : Did you progress on this topic since April ? Maybe in another ticket ?</p> <p>Oh I thought with <a href="https://jira.whamcloud.com/browse/LU-9735" title="Sles12Sp2 and 2.9 getcwd() sometimes fails" class="issue-link" data-issue-key="LU-9735"><del>LU-9735</del></a> being closed this was not a pressing issue. I can look at it. Just need to find a few cycles to work on this.</p> <p>Indeed with <a href="https://jira.whamcloud.com/browse/LU-9735" title="Sles12Sp2 and 2.9 getcwd() sometimes fails" class="issue-link" data-issue-key="LU-9735"><del>LU-9735</del></a>, the occurences have dramatically decreased, but there are still a few left.</p> <p>No pressure though, I was just looking for information on progress.</p> <p>Thanks,</p> <p>Seb.</p> <p>I have been looking at how to resolve these issues and thinking of some ideas. So the breakage you see is due to the way Lustre manages its dcache so the special .lustre/fid directory works. This special handling is what is causing these problems. The patches from upstream resolve the issues you see but end up making the .lustre/fid handling not work. I cover why under ticket <a href="https://jira.whamcloud.com/browse/LU-11501" title="use the dcache properly with .lustre/fid" class="issue-link" data-issue-key="LU-11501">LU-11501</a> what that breakage is. Additional the special .lustre/fid directory doesn't work with file sets so I really need to think of a way to handle all these conditions.</p> <p>Before we can land the patches under these tickets .lustre/fid needs to be resolved first. What I have been thinking of is using a overlayfs type approach which used d_real() to map a dentry to a real dentry under the hood. This way a dentry for .lustre/fid/$FID can then be mapped to the real dentry. This means moving the .lustre/fid dentry out of the dcache into its own private cache for lookup. This is needed anyways since you don't want a mounted file set being able to FID outside of its tree. Also at the same time work is being done in the tools to move away from using .lustre/fid to using fhandles. This might help to resolve some of the issues as well.</p> <p><del>James Simmons (jsimmons@infradead.org) uploaded a new patch:</del> <a href="https://review.whamcloud.com/37013" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37013</a><br/> <del>Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: dcache/namei fixes for lustre</del><br/> <del>Project: fs/lustre-release</del><br/> <del>Branch: master</del><br/> <del>Current Patch Set: 1</del><br/> <del>Commit: b148c9e3f634ecff0b766d3ae89f27440690c001</del></p> <p>Neil Brown (neilb@suse.de) uploaded a new patch: <a href="https://review.whamcloud.com/37741" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37741</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: remove lld_it field of ll_dentry_data<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: c21a2a28bd71d9fe4468c211cb64dc8ca27174e1</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/37741/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37741/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: remove lld_it field of ll_dentry_data<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: f172a59c99f7c6a3398b5f590f4cf1cecabdaee4</p> <p><del>Oleg Drokin (green@whamcloud.com) merged in patch</del> <a href="https://review.whamcloud.com/24175/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/24175/</a><br/> <del>Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: Get rid of ll_dcompare</del><br/> <del>Project: fs/lustre-release</del><br/> <del>Branch: master</del><br/> <del>Current Patch Set:</del><br/> <del>Commit: 787231f53ab63c72634250f8fe9d27bc66cc4e46</del></p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/44135" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/44135</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> lustre: switch to use of -&gt;d_init()<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: c704d8547f63613b34c96151f9451f407f0ef664</p> <p>"Oleg Drokin &lt;green@whamcloud.com&gt;" merged in patch <a href="https://review.whamcloud.com/44135/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/44135/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> lustre: switch to use of -&gt;d_init()<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 57569871375dd857a89e5e03524d0eec093fef5d</p> <p>"James Simmons &lt;jsimmons@infradead.org&gt;" uploaded a new patch: <a href="https://review.whamcloud.com/c/fs/lustre-release/+/49237" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/49237</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9868" title="dcache/namei fixes for lustre" class="issue-link" data-issue-key="LU-9868">LU-9868</a> llite: remove lld_nfs_dentry flag<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 66e550a888a89e333033b8d19e14f4e1b41ca1c9</p> Duplicate LU-16179 Related LU-11501 LU-9735 LU-12997 LU-13486 LU-12511 Development Rank 1|hzzief: Rank (Obsolete) 9223372036854775807 Severity