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-1430 Lustre <p>Currently after device address is changed tunefs should be started with<br/> "writeconf" options. This erase configuration logs for the filesystem<br/> that this server is part of, and regenerate them. This is very dangerous.<br/> All clients must be unmounted and servers for this filesystem should be<br/> stopped. All targets (OSTs/MDTs) must then be restarted to regenerate<br/> logs. No clients should be started until all targets have restarted.<br/> The targets start order is also important. Wrong order can be cause of<br/> failure.</p> Lustre 2.x LU-1430

Changing network address without --writeconf option

New Feature Minor Resolved Fixed Jian Yu Artem Blagodarenko patch Mon, 21 May 2012 16:53:12 +0000 Mon, 29 May 2017 03:46:45 +0000 Mon, 29 May 2017 03:46:45 +0000 Lustre 2.4.0 0 9 <p>patch in RB<br/> <a href="http://review.whamcloud.com/2896" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/2896</a></p> <p>Happy to see this feature being landed.</p> <p>Have you given any thought to reviving Nathan's patches to clean up conf_param to match the set_param syntax in <a href="https://bugzilla.lustre.org/show_bug.cgi?id=17471" class="external-link" target="_blank" rel="nofollow noopener">https://bugzilla.lustre.org/show_bug.cgi?id=17471</a>, to simplify other user configuration tasks?</p> <p>I have forwarded this question to Nathan. Change conf_param to match the set_param is good idea, but Nathan should set priority for this, because I have some other tasks in progress now. </p> <p>Thanks for comments in review board.</p> <p>Hi Andreas - <br/> actually the other day I had an idea which may be both easy and effective: replace the whole conf_param "direct" proc access with a simple upcall-type mechanism from the MGC. </p> <ol> <li>on MGS: lctl conf_param random-proc-string=random-value-string</li> <li>gets added to all the config logs, or alternatively a single special param log</li> <li>param log updates get pulled by all the clients and servers</li> <li>MGC executes via upcall-type mechanism to userspace (i.e. an ioctl) a local lctl set_param string=value</li> </ol> <p>Benefits:</p> <ul> <li>identical conf_param / set_param</li> <li>"permanent" wildcarding in strings</li> <li>no unimplemented conf_param paths (e.g. ptlrpc services)</li> <li>simpler implementation</li> </ul> <p>We currently have this sitting in our backlog pile, although personally this bugs the hell out of me.</p> <p>Xyratex <a href="http://jira-nss.xy01.xyratex.com:8080/browse/MRP-397" class="external-link" target="_blank" rel="nofollow noopener">MRP-397</a></p> <p>Can this be landed?</p> <p>Documentation for this feature is being tracked on:</p> <p><a href="http://jira.whamcloud.com/browse/LUDOC-98" class="external-link" rel="nofollow">http://jira.whamcloud.com/browse/LUDOC-98</a></p> <p>This ticket needs to be allocated to someone closer to this work than me.</p> <p>Resources are available to introduce the documentation change workflow (it is pretty much identical to code changes):<br/> <a href="http://wiki.whamcloud.com/display/PUB/Making+changes+to+the+Lustre+Manual" class="external-link" target="_blank" rel="nofollow noopener">http://wiki.whamcloud.com/display/PUB/Making+changes+to+the+Lustre+Manual</a><br/> Feedback, comments to improve these resources are most welcome.</p> <p>This feature needs an entry in the User Manual. Nathan or Artem, can you prepare the documentation against <a href="https://jira.whamcloud.com/browse/LUDOC-98" title="Document new lctl replace_nids feature" class="issue-link" data-issue-key="LUDOC-98"><del>LUDOC-98</del></a>.</p> <p>Nathan,<br/> regarding your question (which I didn't originally see, because I wasn't CC'd on the bug), I think this wouldn't be a bad idea. Unifying the conf_param and set_param code would be great.</p> <p>I also like the idea of being able to permanently keep the "wildcard" for the parameters.</p> <p>That should definitely be a separate bug than this one.</p> <p>For this bug, it would be great if "lctl replace_nids" could be used to fix <a href="https://jira.whamcloud.com/browse/LU-2200" title="Test failure on test suite conf-sanity, subtest test_32a" class="issue-link" data-issue-key="LU-2200"><del>LU-2200</del></a> (conf-sanity.sh test_32a upgrade test) so that the filesystem images can have their NIDs rewritten to work with o2ib networking. I don't necessarily think that is a prerequisite for landing, but it definitely would provide a more robust test than the current "replace the NIDs with the same NIDs" test that is included in the patch.</p> <blockquote><p>Nathan or Artem, can you prepare the documentation against <a href="https://jira.whamcloud.com/browse/LUDOC-98" title="Document new lctl replace_nids feature" class="issue-link" data-issue-key="LUDOC-98"><del>LUDOC-98</del></a>.</p></blockquote> <p>Done.</p> <p>Patch in <a href="http://review.whamcloud.com/2896" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/2896</a> was landed on master branch.</p> <blockquote> <p>regarding your question (which I didn't originally see, because I wasn't CC'd on the bug), I think this wouldn't be a bad idea. Unifying the conf_param and set_param code would be great.<br/> I also like the idea of being able to permanently keep the "wildcard" for the parameters.<br/> That should definitely be a separate bug than this one.</p></blockquote> <p>Added as <a href="https://jira.whamcloud.com/browse/LU-2629" title="set_param and conf_param have different syntaxes" class="issue-link" data-issue-key="LU-2629"><del>LU-2629</del></a></p> <p>&gt;Have you given any thought to reviving Nathan's patches to clean up conf_param to match the set_param &gt;syntax in <a href="https://bugzilla.lustre.org/show_bug.cgi?id=17471" class="external-link" target="_blank" rel="nofollow noopener">https://bugzilla.lustre.org/show_bug.cgi?id=17471</a>, to simplify other user configuration tasks?</p> <p>This idea is realized here.<br/> <a href="https://jira.hpdd.intel.com/browse/LU-3155" class="external-link" target="_blank" rel="nofollow noopener">https://jira.hpdd.intel.com/browse/LU-3155</a></p> <p>I tried `lctl replace_nids' several days ago and it didn't work for me in my case where the MGS NID has to be changed also. I followed the instructions. From I understanding, it has to run a command on the targets to change the MGS NID.</p> <p>Please let me know if I misuse the command.</p> Related LU-2200 LUDOC-98 Development Rank 1|hzvnof: Rank (Obsolete) 7651