<div dir="ltr"><table cellpadding="0" class="gmail-cf gmail-An" id="gmail-undefined" style="width:706px;table-layout:fixed;border-spacing:0px"><tbody><tr><td class="gmail-Ap" style="vertical-align:top;width:706px;height:100px"><div id="gmail-:2zl" class="gmail-Ar gmail-Au" style="border-radius:1px;box-sizing:border-box;padding:0px 0px 16px;zoom:1;border:0px;margin:0px"><div class="gmail-aO7" style=""></div></div></td></tr></tbody></table><table cellpadding="0" class="gmail-cf gmail-An" id="gmail-undefined" style="width:706px;table-layout:fixed;border-spacing:0px"><tbody><tr><td class="gmail-Ap" style="vertical-align:top;width:706px;height:100px"><div id="gmail-:2zl" class="gmail-Ar gmail-Au" style="border-radius:1px;box-sizing:border-box;padding:0px 0px 16px;zoom:1;border:0px;margin:0px"><div class="gmail-aO7" style=""></div></div></td></tr></tbody></table>Hello Ms everybody<div><br></div><div>I had a case that i had solved</div><div><br></div><div>Brief description of the case:i couldn't not mount the MDT ,MDS and the OSSs.</div><div><br></div><div>when i executed the command # mount -t lustre /dev/sdX   /YY</div><div>The result = it does in fact mount the lustre file system four about 2 to 3 seconds after that nothing</div><div>Th command # lctl dl  ===> does return nothing</div><div><br></div><div>I suspected the lustre network ===> but everything was ok</div><div><br></div><div><br></div><div>I run the debug command just straight away after executing the mounting command in the following order</div><div><br></div><div># mount -t lustre /dev/X  /YY</div><div><br></div><div># lctl dk to have the debug output to see what is happening </div><div><br></div><div>i had a huge output and many lines , but i resume ; which catch my attention was</div><div><br></div><div>specially this portion, or these few lines:</div><div>00080000:10000000:8.0:1621283834.301909:0:10966:0:(osd_handler.c:4945:osd_index_try()) lustre-MDT0000: index object [0x200000003:0x36:0x0] (8/32) registered<br>00000020:01000004:8.0:1621283834.303304:0:10966:0:(obd_mount_server.c:314:server_mgc_clear_fs()) Unassign mgc disk<br>00000020:01000004:8.0:1621283834.303321:0:10966:0:(obd_mount_server.c:1840:server_fill_super_common()) Server sb, dev=41<br>00000020:01000004:43.0:1621283834.323105:0:11049:0:(obd_mount_server.c:1554:server_put_super()) server put_super lustre-MDT0000<br>10000000:01000000:43.0:1621283834.323113:0:11049:0:(mgc_request.c:535:config_log_end()) end config log lustre-client (0)<br><font color="#0000ff"><b style="background-color:rgb(255,255,0)">00000100:00080000:43.0:1621283834.323120:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT0000_UUID INVALID</b></font><br>00000100:00080000:43.0:1621283834.323124:0:11049:0:(pinger.c:412:ptlrpc_pinger_del_import()) removing pingable import lustre-MDT0000-lwp-MDT0000_UUID->lustre-MDT0000_UUID<br><span style="background-color:rgb(255,255,0)">00000100:00080000:43.0:1621283834.323127:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT0000_UUID INVALID</span><br></div><div><br></div><div><br></div><div>This means that it does complain about the UUID</div><div><br></div><div>I found the problem ,the solution was checking the UUID of the disk that i wanted to mount and it is UUID in the fstab file</div><div><br></div><div>the disk changed it is UUID because i have formatted it many times (lustre file system and just an ext4 filesystem as well)</div><div><br></div><div>after checking the UUIDs were different so, i have to pick up the correct one from the fstab file (that is the first one with which i have formatted the disk of lustre file system)</div><div><br></div><div><br></div><div>i tried as well with the command # tunefs.lustre --writeconf  /dev/sdXX  ========> no results (it didn't in fact erase nothing, no changes.)</div><div><br></div><div>the lustre file system just won't mount</div><div><br></div><div>At last the solution:</div><div><br></div><div>-use tune2fs as follow#<span style="background-color:rgb(255,255,0)"><b>tune2fs -O uninit_bg -m 1 -U 5b611acd-e5f8-4976-a063-dd867cdbbc62 /dev/sdX</b></span></div><div><br></div><div>The UUID used here is the one in the fstab file</div><div><br></div><div>if you have an error message or it just won't change the UUID  (then you have to format the disk to ext4 , if you don't have any data on it).</div><div><br></div><div><br></div><div>Finally you can mount the MDS,MDT and the OSSs with no problem.</div><div><br></div><div>That was all.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 19 mai 2021 à 22:10, Ms. Megan Larko via lustre-discuss <<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>The caching could be skewing your performance results.   Try writing a file larger than the amount of memory on the LFS servers.</div><div><br></div><div>Another nice item is the SuperComputing IO500 (and IO50 for smaller systems).  There are instructions for benchmarking storage in ways which can compare to other results for a good idea of the performance ability of your storage.   There are also ideas on avoiding caching issues, etc.</div><div>(Ref <a href="http://io500.org" target="_blank">io500.org</a> )  Disclaimer:  I am not associated with either SuperComputing nor the IO group.</div><div><br></div><div>Cheers,</div><div>megan</div></div>
_______________________________________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org" target="_blank">lustre-discuss@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Tahari.Abdeslam</div>