[lustre-discuss] Benchmarking Lustre, reduce caching

[Abdeslam Tahari]

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 <
lustre-discuss at lists.lustre.org> 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
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>


-- 
Tahari.Abdeslam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20210520/448afaca/attachment.html>