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-5815 Lustre <p>"d_count" is defined at<br/> lustre 2.6.0<br/> lustre/include/linux/lustre_patchless_compat.h, line 123<br/> and<br/> sles11sp3 3.0.101-0.35.0<br/> include/linux/dcache.h, line 153.</p> <p>The '#define d_count' is new in sles11sp3 3.0.101-0.35.1, (Not in -0.31.1)<br/> and '#define d_count' was named '#define d_refcount' in 2.4.3.</p> <p>Now we have redefined symbols.</p> LU-5815

d_count redefined in lustre 2.6.0 and in sles11sp3 3.0.101-0.35.1

Bug Major Resolved Won't Fix Bob Glossman Jay Lan Mon, 27 Oct 2014 23:52:07 +0000 Mon, 19 Oct 2015 21:41:56 +0000 Mon, 19 Oct 2015 21:41:56 +0000 Lustre 2.6.0 0 3 <p>Bob</p> <p>Could you please comment on this one?</p> <p>Thanks</p> <p>Peter</p> <p>This is fixed in master. The kernel update mod for 3.0.101-0.35, commit 3000a83dcd3c201f383c0507d33e7861fc695997, includes changes to take care of this. To quote from the commit header:</p> <p>Create and use ll_d_count() wrapper to solve<br/> build problem caused by linux #include changes.</p> <p>b2_6 doesn't have this mod &amp; therefore can not build on the latest sles11sp3 kernels.</p> <p>Is there plan to port "kernel update for 3.0.101-0.35" and "kernel update for 3.0.101-0.40" to b2_6?</p> <p>We are running 3.0.101-0.31. Our next kernel would be 3.0.101-0.40.</p> <p>Jay</p> <p>There is not presently a plan to do this but if this is something that NASA would like to run in production this is certainly something that we could help with.</p> <p>Peter</p> <p>Please close it as WONT FIX.<br/> We are not going to use 2.6 and not sure if next lustre would be 2.7 or 2.8 and we most likely would be running sles12 at that time.</p> <p>I will open a new case if we still hit this problem on next generation of lustre and kernel.</p> <p>ok Jay</p> Development Rank 1|hzwzlb: Rank (Obsolete) 16304 Severity