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-15091 Lustre <p>After renaming a file system and updating NIDs on the targets, MDT0000 fails to mount with the following error:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>LustreError: 157-3: Trying to start OBD ls3-MDT0000_UUID using the wrong disk ls30000_UUID. Were the /dev/ assignments rearranged? </pre> </div></div> <p>Note that lsd-&gt;lsd_uuid is missing "-MDT" between the fs name ("ls3") and the MDT index ("0000").</p> <p>The rename was probably accomplished with:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>tunefs.lustre --writeconf --fsname=ls3 --rename=lustre3 -v asp1/mdt1 </pre> </div></div> <p>And the NID update was probably accomplished with:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>tunefs.lustre --param=mgsnode=172.19.1.141@o2ib100:172.19.1.142@o2ib100 --param=failover.node=172.19.1.141@o2ib100:172.19.1.142@o2ib100 asp1/mdt1 </pre> </div></div> <p>Unfortunately I no longer have the output from those commands, and I'm not certain exactly when this occurred.</p> <p>This only occurred on one MDT out of 12 targets (4 MDT 8 OST). I don't know why this one was different.</p> <p>I don't think this is enough information to find the root cause and fix it, but am creating the issue in hopes it prompts anyone else who sees this issue to document what led up to it.</p> zfs-2.1.0_1llnl <br/> lustre-2.14.0_5.llnl <br/> 4.18.0-305.7.1.1toss.t4.x86_64 <br/> rhel 8.4 LU-15091

Trying to start OBD ls3-MDT0000_UUID using the wrong disk ls30000_UUID. Were the /dev/ assignments rearranged

Bug Minor Open Unresolved Yang Sheng Olaf Faaland llnl Tue, 12 Oct 2021 20:25:58 +0000 Mon, 18 Oct 2021 22:53:09 +0000 Lustre 2.14.0 0 2 <p>Peter, I didn't label this topllnl because of the insufficient information.</p> <p>I am not certain, but it seems as if the only problem was the file system name in last_recvd. I stopped all the targets, mounted the dataset as type zfs ("mount -t zfs asp1/mdt1 /mnt/foo"), used a hex editor to alter /mnt/foo/last_recvd and set the correct target name at offset 0 in the file, and umounted /mnt/foo. That allowed the mount to proceed.</p> <p>Yang Sheng</p> <p>Any suggestions here?</p> <p>Peter</p> <p>For my reference, my local ticket is TOSS5317</p> Development Rank 1|i0270f: Rank (Obsolete) 9223372036854775807 Severity