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-2757 Lustre <p>Commit 43603bd1 (<a href="https://jira.whamcloud.com/browse/LU-1548" title="Test failure on test suite mds-survey, subtest test_1" class="issue-link" data-issue-key="LU-1548"><del>LU-1548</del></a> osd: move i_htree_lock to iam container) eliminated the use of dynlocks inside ldiskfs. Now that it's only used in the system-agnostic mdd and osd-ldiskfs code, we can move it under lustre/ and eliminate a patch we apply during build.</p> LU-2757

Move dynlocks out of ldiskfs

Improvement Minor Resolved Fixed Bob Glossman Jeff Mahoney patch Tue, 5 Feb 2013 18:36:46 +0000 Tue, 24 Sep 2013 15:24:36 +0000 Tue, 24 Sep 2013 15:24:36 +0000 Lustre 2.5.0 0 4 <p>The mdd layer uses the dynlock code. How did it ever work on ZFS?</p> <p>With the current patch the dynlock code in placed in lustre/dynlocks. Andreas where do recommend that it be placed in the tree? Would obdclass make a logical choice since this code is used by mdd and osd-ldiskfs layers?</p> <p>I was wondering that too when I was build testing and the mdd Makefile didn't have the proper include path. The mdd layer <b>can</b> use the dynlock code but isn't currently because MDD_DISABLE_PDO_LOCK is set. The comment indicates it's because it's already protected by the LDLM.</p> <p>Is it just me or is build of dynlocks.c failing to find dynlocks.h ?<br/> Seems to be missing a -I in new lustre/dynlocks/Makefile.in</p> <p>My builds succeed but you're right, there should be a -I in there.</p> <p>The 1 line fix below seems to fix it for me.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> --- a/lustre/dynlocks/Makefile.in +++ b/lustre/dynlocks/Makefile.in @@ -2,7 +2,7 @@ all: modules install: modules_install distdir: -EXTRA_CFLAGS += -include @abs_top_builddir@/config.h +EXTRA_CFLAGS += -include @abs_top_builddir@/config.h -I@abs_top_builddir@/lustre/dynlocks sources := dynlocks.c dynlocks.h </pre> </div></div> <p>I think that should probably be:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> --- a/lustre/dynlocks/Makefile.in +++ b/lustre/dynlocks/Makefile.in @@ -2,7 +2,7 @@ all: modules install: modules_install distdir: -EXTRA_CFLAGS += -include @abs_top_builddir@/config.h +EXTRA_CFLAGS += -include @abs_top_builddir@/config.h -I@abs_srcdir@ sources := dynlocks.c dynlocks.h </pre> </div></div> <p>If dynlocks is going to be a whole new kernel module as proposed in the patch, then it will need some work to be dealt with properly in various tools like 'lctl modules' and lustre_rmmod.</p> <p>Yuck. Where this code goes depends on if the mdd layer will ever use dynlock. If it wouldn't then it can be moved to osd-ldiskfs. If dynlock will be used with mdd then I suggest it go into the obdclass. </p> <p>Ok, it makes sense to add it to an already existing dependency of both oxd-ldiskfs and mdd. I'll update the patch to move it to obdclass.</p> <p>Updated the patch Alex as you suggested. Now that 2.4 is frozen we can label this a 2.5 item</p> <p><a href="http://review.whamcloud.com/5282" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5282</a></p> <p>This patch has just landed. Peter you can close this ticket.</p> Duplicate LU-2564 Development Rank 1|hzvimv: Rank (Obsolete) 6690