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-3006 Lustre <p>While preparing for our test shot after we formatted the new file system we remembered to add the failover nids for IR testing. So we umounted the file system and used tunefs.lustre to add the failover nids. Then proceeded remount the file system in order of MGS, MDT, then serially the OSTs. After mounting a client to validate that the proper failover nids toke hold we discovered that in the osc imports failover nids were never updated. So with a second try we ran tunefs.lustre to remove the failover nids. Then started and stopped the file system. Added the failover nids with tunefs.lustre and then restarted the file system the second time. Again lctl get_param osc-*..../import | grep failover_nids did not show the failover nids getting updated.</p> Lustre 2.3.61 server. The lack of failover nids in the osc imports field also happens on 1.8 clients so it is a server side issue. LU-3006

failover nids added after format don't propogate to clients

Bug Blocker Resolved Fixed Alex Zhuravlev James A Simmons MB Thu, 21 Mar 2013 14:17:43 +0000 Wed, 15 May 2013 22:22:45 +0000 Sat, 27 Apr 2013 20:02:48 +0000 Lustre 2.4.0 Lustre 2.4.0 0 9 <p>what arguments do you use tunefs.lustre? the --failnode should be used with IP address instead of hostname.</p> <p>The host name for the servers only exist on the ethernet ports which is used for remote management. We only use IP addresses for the infiniband ports.</p> <p>a patch is posted at <a href="http://review.whamcloud.com/5817" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5817</a></p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedHeader panelHeader" style="border-bottom-width: 1px;"><b>commit message</b></div><div class="preformattedContent panelContent"> <pre>LU-3006 obdclass: pass disk conf param to kernel Commit 31db8f9cf048ef93477951e12a166722e777a2da has disabled LDD_F_UPDATE in mti-&gt;mti_flags and only enable it when 'writeconf' is used or for the newly formatted target. This will fail to pass failnode params set by tunefs.lustre. This patch passes LDD_F_UPDATE flag directly down to mti_flags despite whether it is set through mkfs or by tunefs. Also fixes two test script glitches. </pre> </div></div> <p>Tested the patch. When I do a tunefs.lustre --erase-param --failnode=10.37.248.63o2ib1 /dev/mapper/barry1a-l0 on the client I see </p> <p>lctl get_param osc.lustre-OST0000-osc-*.import | grep failover_nids<br/> failover_nids: <span class="error">&#91;10.37.248.62@o2ib1, 10.37.248.63@o2ib1&#93;</span></p> <p>Is that normal? I only want one failover nid.</p> <p>I think it is normal, the failover nid lists all service nids, the first one is the preferable one.</p> <p>Alex Zhuravlev Mar 29</p> <p>Patch Set 1: I would prefer that you didn't submit this</p> <p>(1 inline comment)</p> <p>given UPDATE is not cleared upon mount, we would lead to rewriting a profile on every mount.. i don't think this is good. we need to decide whether we need to modify mountdata to clear UPDATE flag as we were doing previously or we disable this functionality in tunefs.</p> <p>So as I understand it this patch isn't going to be accepted and the tunefs.lustre syntax for setting failover nids will not be supported moving forward, correct? Was this a purposeful change? Where is the documentation update for this &#8211; it is not reflected in the current lustre 2.4 (see section 30.1.3 for MDS failover 36.18.3 for tunefs.lustre options documentation). Will this be updated and announced? This is a major shift from previous versions &#8211; and has not been discussed at length. I know Andreas has talked a lot about the tuneables in /proc not being settable via command line but this is far different from that scenario.</p> <p>As per Oleg, Alex is thinking about how to address this</p> <p>I'm tempted to introduce another delimiter in the label to store UPDATE.. should be enough and trivial to implement. any thoughts?</p> <p>As long as it preserves previous behavior it sounds reasonable. Looking forward to a patch for this.</p> <p><a href="http://review.whamcloud.com/5982" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5982</a></p> <p>Alex, I'm not a big fan of abusing the label for an increasing number of different flag meanings. The main problem is that this permanently changes the target name that is visible to applications, and there are times when it is not reset. For example, this would prevent the filesystem from being mounted by label after a reboot.</p> <p>Is there no other field we can use to pass information to the MGS?</p> <p>Alex, did we come up with a solution to this problem? This is one of the more noticeable regressions in 2.4.0 for end users.</p> <p>not a final one, but the idea was to search for another place in the superblock to store the flag. working on this...</p> <p>landed</p> Related LU-3244 LU-3352 LU-3167 Development Rank 1|hzvluv: Rank (Obsolete) 7319 Severity