Hello Ms everybody I had a case that i had solved
Brief description of the case:i couldn't not mount the MDT ,MDS and the OSSs. when i executed the command # mount -t lustre /dev/sdX /YY The result = it does in fact mount the lustre file system four about 2 to 3 seconds after that nothing Th command # lctl dl ===> does return nothing I suspected the lustre network ===> but everything was ok I run the debug command just straight away after executing the mounting command in the following order # mount -t lustre /dev/X /YY # lctl dk to have the debug output to see what is happening i had a huge output and many lines , but i resume ; which catch my attention was specially this portion, or these few lines: 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 00000020:01000004:8.0:1621283834.303304:0:10966:0:(obd_mount_server.c:314:server_mgc_clear_fs()) Unassign mgc disk 00000020:01000004:8.0:1621283834.303321:0:10966:0:(obd_mount_server.c:1840:server_fill_super_common()) Server sb, dev=41 00000020:01000004:43.0:1621283834.323105:0:11049:0:(obd_mount_server.c:1554:server_put_super()) server put_super lustre-MDT0000 10000000:01000000:43.0:1621283834.323113:0:11049:0:(mgc_request.c:535:config_log_end()) end config log lustre-client (0) *00000100:00080000:43.0:1621283834.323120:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT0000_UUID INVALID* 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 00000100:00080000:43.0:1621283834.323127:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT0000_UUID INVALID This means that it does complain about the UUID 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 the disk changed it is UUID because i have formatted it many times (lustre file system and just an ext4 filesystem as well) 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) i tried as well with the command # tunefs.lustre --writeconf /dev/sdXX ========> no results (it didn't in fact erase nothing, no changes.) the lustre file system just won't mount At last the solution: -use tune2fs as follow#*tune2fs -O uninit_bg -m 1 -U 5b611acd-e5f8-4976-a063-dd867cdbbc62 /dev/sdX* The UUID used here is the one in the fstab file 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). Finally you can mount the MDS,MDT and the OSSs with no problem. That was all. Le mer. 19 mai 2021 à 22:10, Ms. Megan Larko via lustre-discuss < [email protected]> a écrit : > Hello, > > The caching could be skewing your performance results. Try writing a > file larger than the amount of memory on the LFS servers. > > 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. > (Ref io500.org ) Disclaimer: I am not associated with either > SuperComputing nor the IO group. > > Cheers, > megan > _______________________________________________ > lustre-discuss mailing list > [email protected] > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > -- Tahari.Abdeslam
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
