Re: [lustre-discuss] Unable to mount new OST
Hello I think you have a disk problem , bad blocks which is causing the problem , unmount the disk and run e2fsck and repair the bad blocks as well (man e2fsck) Le mar. 6 juil. 2021 à 09:28, David Cohen a écrit : > Thanks Artem, > I already tried that (e2fsck) with no avail. > I even tried tunefs.lustre --writeconf --erase-params on the MDS and all > the other targets, but the behaviour remains the same. > > Best regards, > David > > > > On Tue, Jul 6, 2021 at 10:09 AM Благодаренко Артём < > artem.blagodare...@gmail.com> wrote: > >> Hello David, >> >> On 6 Jul 2021, at 08:34, David Cohen >> wrote: >> >> Jul 6 07:39:19 oss03 kernel: LDISKFS-fs (dm-21): warning: mounting fs >> with errors, running e2fsck is recommended >> >> >> >> It looks like LDISKFS partition is in inconsistent state now. It is >> better to follow the recommendation and run e2fsck. >> >> Best regards, >> Artem Blagodarenko. >> >> ___ > lustre-discuss mailing list > lustre-discuss@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > -- Tahari.Abdeslam ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] Unable to mount new OST
Hello could you submit logs files please Le lun. 5 juil. 2021 à 17:05, David Cohen a écrit : > Hi, > I'm using Lustre 2.10.5 and lately tried to add a new OST. > The OST was formatted with the command below, which other than the index > is the exact same one used for all the other OSTs in the system. > > mkfs.lustre --reformat --mkfsoptions="-t ext4 -T huge" --ost > --fsname=local --index=0051 --param ost.quota_type=ug > --mountfsoptions='errors=remount-ro,extents,mballoc' --mgsnode=10.0.0.3@tcp > --mgsnode=10.0.0.1@tc > p --mgsnode=10.0.0.2@tcp --servicenode=10.0.0.3@tcp > --servicenode=10.0.0.1@tcp --servicenode=10.0.0.2@tcp /dev/mapper/OST0051 > > When trying to mount the with: > mount.lustre /dev/mapper/OST0051 /Lustre/OST0051 > > The system stays on 100% CPU (one core) forever and the mount never > completes, not even after a week. > > I tried tunefs.lustre --writeconf --erase-params on the MDS and all the > other targets, but the behaviour remains the same. > > David > ___ > lustre-discuss mailing list > lustre-discuss@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > -- Tahari.Abdeslam ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
[lustre-discuss] The MDT MDS and OSS wont mount (case resolved)
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: 0008:1000:8.0:1621283834.301909:0:10966:0:(osd_handler.c:4945:osd_index_try()) lustre-MDT: index object [0x20003:0x36:0x0] (8/32) registered 0020:0104:8.0:1621283834.303304:0:10966:0:(obd_mount_server.c:314:server_mgc_clear_fs()) Unassign mgc disk 0020:0104:8.0:1621283834.303321:0:10966:0:(obd_mount_server.c:1840:server_fill_super_common()) Server sb, dev=41 0020:0104:43.0:1621283834.323105:0:11049:0:(obd_mount_server.c:1554:server_put_super()) server put_super lustre-MDT 1000:0100:43.0:1621283834.323113:0:11049:0:(mgc_request.c:535:config_log_end()) end config log lustre-client (0) *0100:0008:43.0:1621283834.323120:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT_UUID INVALID* 0100:0008:43.0:1621283834.323124:0:11049:0:(pinger.c:412:ptlrpc_pinger_del_import()) removing pingable import lustre-MDT-lwp-MDT_UUID->lustre-MDT_UUID 0100:0008:43.0:1621283834.323127:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT_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. -- Tahari.Abdeslam ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] Benchmarking Lustre, reduce caching
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: 0008:1000:8.0:1621283834.301909:0:10966:0:(osd_handler.c:4945:osd_index_try()) lustre-MDT: index object [0x20003:0x36:0x0] (8/32) registered 0020:0104:8.0:1621283834.303304:0:10966:0:(obd_mount_server.c:314:server_mgc_clear_fs()) Unassign mgc disk 0020:0104:8.0:1621283834.303321:0:10966:0:(obd_mount_server.c:1840:server_fill_super_common()) Server sb, dev=41 0020:0104:43.0:1621283834.323105:0:11049:0:(obd_mount_server.c:1554:server_put_super()) server put_super lustre-MDT 1000:0100:43.0:1621283834.323113:0:11049:0:(mgc_request.c:535:config_log_end()) end config log lustre-client (0) *0100:0008:43.0:1621283834.323120:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT_UUID INVALID* 0100:0008:43.0:1621283834.323124:0:11049:0:(pinger.c:412:ptlrpc_pinger_del_import()) removing pingable import lustre-MDT-lwp-MDT_UUID->lustre-MDT_UUID 0100:0008:43.0:1621283834.323127:0:11049:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT_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@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@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > -- Tahari.Abdeslam ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] lustre-discuss Digest, Vol 182, Issue 12
Hello Ms Megan
I am happy it is resolved
it was a problem of UUID
I will post later on the solution+ problem
Cheers
Le 19/05/2021 à 13:45, Abdeslam Tahari a écrit :
Hello Ms Megan
Thank you for the reply and your help
I have checked the lctl ping
it seems to be ok the result
lctl ping 10.0.1.70
12345-0@lo
12345-10.0.1.70@tcp
the ping is good it is always ok .
the problem is when i mount the luster file system
mount -t lustre /dev/sda /mds
i have the following output
lctl dl
0 UP osd-ldiskfs lustre-MDT-osd lustre-MDT-osd_UUID 3
2 UP mgc MGC10.0.1.70@tcp 3ec79ce9-5167-9661-9bd6-0b897fcc42f2 4
3 UP mds MDS MDS_uuid 2
if i execute the command for the second time i will have no output at all
and the filesystem in reality is not mounted
i think but i am not sure it complains about the UUID of the MDT
from the output of the
lctl dk
0100:0008:78.0:1621365812.955564:0:84913:0:(pinger.c:413:ptlrpc_pinger_del_import())
removing pingable import
lustre-MDT-lwp-MDT_UUID->lustre-MDT_UUID
0100:0008:78.0:1621365812.955567:0:84913:0:(import.c:86:import_set_state_nolock())
9b985701b800 lustre-MDT_UUID: changing import state from
DISCONN to CLOSED
*0100:0008:78.0:1621365812.955571:0:84913:0:(import.c:157:ptlrpc_deactivate_import_nolock())
setting import lustre-MDT_UUID INVALID*
1000:0100:78.0:1621365812.965420:0:84913:0:(mgc_request.c:151:config_log_put())
dropping config log lustre-mdtir
Kind regards
Le mer. 19 mai 2021 à 03:15, Ms. Megan Larko via lustre-discuss
<mailto:lustre-discuss@lists.lustre.org>> a écrit :
Hello Tahari,
What is the result of "lctl ping 10.0.1.70@tcp_0" from the box on
which you are trying to mount the Lustre File System? Is the
ping successful and then fails after 03 seconds? If yes, you may
wish to check the /etc/lnet.conf file for Lustre LNet path
"discovery" (1 allows LNet discovery while 0 does not), and
drop_asym_route (0 disallows asymmetrical routing while 1 permits
it). I have worked with a few complex networks in which we chose
to turn off LNet discovery and specify, via /etc/lnet.conf, the
routes. On one system the asymmetrical routing (we have 16 LNet
boxes between the system and the Lustre storage) seemed to be a
problem, but we couldn't pin it to any particular box. On that
system disallowing asymmetrical routing seemed to help maintain
LNet/Lustre connectivity.
One may check the lctl ping to narrow down net connectivity from
other possibilities.
Cheers,
megan
On Mon, May 17, 2021 at 3:50 PM
mailto:lustre-discuss-requ...@lists.lustre.org>> wrote:
Send lustre-discuss mailing list submissions to
lustre-discuss@lists.lustre.org
<mailto:lustre-discuss@lists.lustre.org>
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
<http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org>
or, via email, send a message with subject or body 'help' to
lustre-discuss-requ...@lists.lustre.org
<mailto:lustre-discuss-requ...@lists.lustre.org>
You can reach the person managing the list at
lustre-discuss-ow...@lists.lustre.org
<mailto:lustre-discuss-ow...@lists.lustre.org>
When replying, please edit your Subject line so it is more
specific
than "Re: Contents of lustre-discuss digest..."
Today's Topics:
1. Re: problems to mount MDS and MDT (Abdeslam Tahari)
2. Re: problems to mount MDS and MDT (Colin Faber)
--
Message: 1
Date: Mon, 17 May 2021 21:35:34 +0200
From: Abdeslam Tahari mailto:abes...@gmail.com>>
To: Colin Faber mailto:cfa...@gmail.com>>
Cc: lustre-discuss mailto:lustre-discuss@lists.lustre.org>>
Subject: Re: [lustre-discuss] problems to mount MDS and MDT
Message-ID:
mailto:bxecepen5dzzd%2bqxn...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"
Thank you Colin
No i don't have iptables or rules
firewalled is stopped selinux disabled as well
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Regards
Regards
Le lun. 17 mai 2021 ? 21:29, Colin Faber mailto:cfa...@gmail.com>> a ?crit :
> Firewall rules dealing with localhost?
>
>
Re: [lustre-discuss] problems to mount MDS and MDT
here is an attachment of the output of debugging file Le mar. 18 mai 2021 à 01:19, Abdeslam Tahari a écrit : > Will do. > i join an attachment of the debug output > i hope that will help > > Le lun. 17 mai 2021 à 21:50, Colin Faber a écrit : > >> It appears part of the debug data is missing (the part before you posted >> it), Can you try again, lctl dk > /dev/null to clear it then try your mount >> and grab the debug again? >> >> On Mon, May 17, 2021 at 1:35 PM Abdeslam Tahari >> wrote: >> >>> Thank you Colin >>> >>> No i don't have iptables or rules >>> >>> firewalled is stopped selinux disabled as well >>> iptables -L >>> Chain INPUT (policy ACCEPT) >>> target prot opt source destination >>> >>> Chain FORWARD (policy ACCEPT) >>> target prot opt source destination >>> >>> Chain OUTPUT (policy ACCEPT) >>> target prot opt source destination >>> >>> >>> Regards >>> >>> >>> Regards >>> >>> Le lun. 17 mai 2021 à 21:29, Colin Faber a écrit : >>> >>>> Firewall rules dealing with localhost? >>>> >>>> On Mon, May 17, 2021 at 11:33 AM Abdeslam Tahari via lustre-discuss < >>>> lustre-discuss@lists.lustre.org> wrote: >>>> >>>>> Hello >>>>> >>>>> i have a problem to mount the mds/mdt luster, it wont mount at all and >>>>> there is no message errors at the console >>>>> >>>>> -it does not show errors or messages while mounting it >>>>> >>>>> here are some debug file logs >>>>> >>>>> >>>>> i specify it is a new project that i am doing. >>>>> >>>>> the version and packages of luter installed: >>>>> kmod-lustre-2.12.5-1.el7.x86_64 >>>>> kernel-devel-3.10.0-1127.8.2.el7_lustre.x86_64 >>>>> lustre-2.12.5-1.el7.x86_64 >>>>> lustre-resource-agents-2.12.5-1.el7.x86_64 >>>>> kernel-3.10.0-1160.2.1.el7_lustre.x86_64 >>>>> kernel-debuginfo-common-x86_64-3.10.0-1160.2.1.el7_lustre.x86_64 >>>>> kmod-lustre-osd-ldiskfs-2.12.5-1.el7.x86_64 >>>>> kernel-3.10.0-1127.8.2.el7_lustre.x86_64 >>>>> lustre-osd-ldiskfs-mount-2.12.5-1.el7.x86_64 >>>>> >>>>> >>>>> >>>>> the system(os) Centos 7 >>>>> >>>>> the kernel >>>>> Linux lustre-mds1 3.10.0-1127.8.2.el7_lustre.x86_64 >>>>> cat /etc/redhat-release >>>>> >>>>> >>>>> when i mount the luster file-system it wont show up and no errors >>>>> >>>>> mount -t lustre /dev/sda /mds >>>>> >>>>> lctl dl does not show up >>>>> >>>>> df -h no mount point for /dev/sda >>>>> >>>>> >>>>> lctl dl >>>>> >>>>> shows this: >>>>> lctl dl >>>>> 0 UP osd-ldiskfs lustre-MDT-osd lustre-MDT-osd_UUID 3 >>>>> 2 UP mgc MGC10.0.1.70@tcp 57e06c2d-5294-f034-fd95-460cee4f92b7 4 >>>>> 3 UP mds MDS MDS_uuid 2 >>>>> >>>>> >>>>> but unfortunately it disappears after 03 seconds >>>>> >>>>> lctl dl shows nothing >>>>> >>>>> lctl dk >>>>> >>>>> shows this debug output >>>>> >>>>> >>>>> 0020:0080:18.0:1621276062.004338:0:13403:0:(obd_config.c:1128:class_process_config()) >>>>> processing cmd: cf006 >>>>> 0020:0080:18.0:1621276062.004341:0:13403:0:(obd_config.c:1147:class_process_config()) >>>>> removing mappings for uuid MGC10.0.1.70@tcp_0 >>>>> 0020:0104:18.0:1621276062.004346:0:13403:0:(obd_mount.c:661:lustre_put_lsi()) >>>>> put 9bbbf91d5800 1 >>>>> 0020:0080:18.0:1621276062.004351:0:13403:0:(genops.c:1501:class_disconnect()) >>>>> disconnect: cookie 0x256dd92fc5bf929c >>>>> 0020:0080:18.0:1621276062.004354:0:13403:0:(genops.c:1024:class_export_put()) >>>>> final put 9bbf3e66a400/lustre-MDT-osd_UUID >>>>> 0020:0100:18.0:1621276062.004361:0:13403:0:(obd_config.c:2100:class_manual_cleanup()) >>>>> Manual cleanup
Re: [lustre-discuss] problems to mount MDS and MDT
Will do. i join an attachment of the debug output i hope that will help Le lun. 17 mai 2021 à 21:50, Colin Faber a écrit : > It appears part of the debug data is missing (the part before you posted > it), Can you try again, lctl dk > /dev/null to clear it then try your mount > and grab the debug again? > > On Mon, May 17, 2021 at 1:35 PM Abdeslam Tahari wrote: > >> Thank you Colin >> >> No i don't have iptables or rules >> >> firewalled is stopped selinux disabled as well >> iptables -L >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> >> >> Regards >> >> >> Regards >> >> Le lun. 17 mai 2021 à 21:29, Colin Faber a écrit : >> >>> Firewall rules dealing with localhost? >>> >>> On Mon, May 17, 2021 at 11:33 AM Abdeslam Tahari via lustre-discuss < >>> lustre-discuss@lists.lustre.org> wrote: >>> >>>> Hello >>>> >>>> i have a problem to mount the mds/mdt luster, it wont mount at all and >>>> there is no message errors at the console >>>> >>>> -it does not show errors or messages while mounting it >>>> >>>> here are some debug file logs >>>> >>>> >>>> i specify it is a new project that i am doing. >>>> >>>> the version and packages of luter installed: >>>> kmod-lustre-2.12.5-1.el7.x86_64 >>>> kernel-devel-3.10.0-1127.8.2.el7_lustre.x86_64 >>>> lustre-2.12.5-1.el7.x86_64 >>>> lustre-resource-agents-2.12.5-1.el7.x86_64 >>>> kernel-3.10.0-1160.2.1.el7_lustre.x86_64 >>>> kernel-debuginfo-common-x86_64-3.10.0-1160.2.1.el7_lustre.x86_64 >>>> kmod-lustre-osd-ldiskfs-2.12.5-1.el7.x86_64 >>>> kernel-3.10.0-1127.8.2.el7_lustre.x86_64 >>>> lustre-osd-ldiskfs-mount-2.12.5-1.el7.x86_64 >>>> >>>> >>>> >>>> the system(os) Centos 7 >>>> >>>> the kernel >>>> Linux lustre-mds1 3.10.0-1127.8.2.el7_lustre.x86_64 >>>> cat /etc/redhat-release >>>> >>>> >>>> when i mount the luster file-system it wont show up and no errors >>>> >>>> mount -t lustre /dev/sda /mds >>>> >>>> lctl dl does not show up >>>> >>>> df -h no mount point for /dev/sda >>>> >>>> >>>> lctl dl >>>> >>>> shows this: >>>> lctl dl >>>> 0 UP osd-ldiskfs lustre-MDT-osd lustre-MDT-osd_UUID 3 >>>> 2 UP mgc MGC10.0.1.70@tcp 57e06c2d-5294-f034-fd95-460cee4f92b7 4 >>>> 3 UP mds MDS MDS_uuid 2 >>>> >>>> >>>> but unfortunately it disappears after 03 seconds >>>> >>>> lctl dl shows nothing >>>> >>>> lctl dk >>>> >>>> shows this debug output >>>> >>>> >>>> 0020:0080:18.0:1621276062.004338:0:13403:0:(obd_config.c:1128:class_process_config()) >>>> processing cmd: cf006 >>>> 0020:0080:18.0:1621276062.004341:0:13403:0:(obd_config.c:1147:class_process_config()) >>>> removing mappings for uuid MGC10.0.1.70@tcp_0 >>>> 0020:0104:18.0:1621276062.004346:0:13403:0:(obd_mount.c:661:lustre_put_lsi()) >>>> put 9bbbf91d5800 1 >>>> 0020:0080:18.0:1621276062.004351:0:13403:0:(genops.c:1501:class_disconnect()) >>>> disconnect: cookie 0x256dd92fc5bf929c >>>> 0020:0080:18.0:1621276062.004354:0:13403:0:(genops.c:1024:class_export_put()) >>>> final put 9bbf3e66a400/lustre-MDT-osd_UUID >>>> 0020:0100:18.0:1621276062.004361:0:13403:0:(obd_config.c:2100:class_manual_cleanup()) >>>> Manual cleanup of lustre-MDT-osd (flags='') >>>> 0020:0080:18.0:1621276062.004368:0:821:0:(genops.c:974:class_export_destroy()) >>>> destroying export 9bbf3e66a400/lustre-MDT-osd_UUID for >>>> lustre-MDT-osd >>>> 0020:0080:18.0:1621276062.004376:0:13403:0:(obd_config.c:1128:class_process_config()) >>>> processing cmd: cf004 >>>> 0020:0080:18.0:1621276062.004379:0:13403:0:(obd_config.c:659:class_cleanup()) >>>> lustre-MDT-osd: forcing exports to di
Re: [lustre-discuss] lustre-discuss Digest, Vol 182, Issue 12
Hello Ms Megan Thank you for the reply and your help I have checked the lctl ping it seems to be ok the result lctl ping 10.0.1.70 12345-0@lo 12345-10.0.1.70@tcp the ping is good it is always ok . the problem is when i mount the luster file system mount -t lustre /dev/sda /mds i have the following output lctl dl 0 UP osd-ldiskfs lustre-MDT-osd lustre-MDT-osd_UUID 3 2 UP mgc MGC10.0.1.70@tcp 3ec79ce9-5167-9661-9bd6-0b897fcc42f2 4 3 UP mds MDS MDS_uuid 2 if i execute the command for the second time i will have no output at all and the filesystem in reality is not mounted i think but i am not sure it complains about the UUID of the MDT from the output of the lctl dk 0100:0008:78.0:1621365812.955564:0:84913:0:(pinger.c:413:ptlrpc_pinger_del_import()) removing pingable import lustre-MDT-lwp-MDT_UUID->lustre-MDT_UUID 0100:0008:78.0:1621365812.955567:0:84913:0:(import.c:86:import_set_state_nolock()) 9b985701b800 lustre-MDT_UUID: changing import state from DISCONN to CLOSED *0100:0008:78.0:1621365812.955571:0:84913:0:(import.c:157:ptlrpc_deactivate_import_nolock()) setting import lustre-MDT_UUID INVALID* 1000:0100:78.0:1621365812.965420:0:84913:0:(mgc_request.c:151:config_log_put()) dropping config log lustre-mdtir Kind regards Le mer. 19 mai 2021 à 03:15, Ms. Megan Larko via lustre-discuss < lustre-discuss@lists.lustre.org> a écrit : > Hello Tahari, > What is the result of "lctl ping 10.0.1.70@tcp_0" from the box on which > you are trying to mount the Lustre File System? Is the ping successful > and then fails after 03 seconds? If yes, you may wish to check the > /etc/lnet.conf file for Lustre LNet path "discovery" (1 allows LNet > discovery while 0 does not), and drop_asym_route (0 disallows > asymmetrical routing while 1 permits it). I have worked with a few > complex networks in which we chose to turn off LNet discovery and specify, > via /etc/lnet.conf, the routes. On one system the asymmetrical routing (we > have 16 LNet boxes between the system and the Lustre storage) seemed to be > a problem, but we couldn't pin it to any particular box. On that system > disallowing asymmetrical routing seemed to help maintain LNet/Lustre > connectivity. > > One may check the lctl ping to narrow down net connectivity from other > possibilities. > > Cheers, > megan > > On Mon, May 17, 2021 at 3:50 PM > wrote: > >> Send lustre-discuss mailing list submissions to >> lustre-discuss@lists.lustre.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org >> or, via email, send a message with subject or body 'help' to >> lustre-discuss-requ...@lists.lustre.org >> >> You can reach the person managing the list at >> lustre-discuss-ow...@lists.lustre.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of lustre-discuss digest..." >> >> >> Today's Topics: >> >>1. Re: problems to mount MDS and MDT (Abdeslam Tahari) >>2. Re: problems to mount MDS and MDT (Colin Faber) >> >> >> -- >> >> Message: 1 >> Date: Mon, 17 May 2021 21:35:34 +0200 >> From: Abdeslam Tahari >> To: Colin Faber >> Cc: lustre-discuss >> Subject: Re: [lustre-discuss] problems to mount MDS and MDT >> Message-ID: >> > bxecepen5dzzd+qxn...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Thank you Colin >> >> No i don't have iptables or rules >> >> firewalled is stopped selinux disabled as well >> iptables -L >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> >> >> Regards >> >> >> Regards >> >> Le lun. 17 mai 2021 ? 21:29, Colin Faber a ?crit : >> >> > Firewall rules dealing with localhost? >> > >> > On Mon, May 17, 2021 at 11:33 AM Abdeslam Tahari via lustre-discuss < >> > lustre-discuss@lists.lustre.org> wrote: >> > >> >> Hello >> >> >> >> i have a problem to mount the mds/mdt luster, it wont mount at all and >> >> there is no message errors at the console >> >> >> >> -it does not show errors or messages while mounting it
Re: [lustre-discuss] problems to mount MDS and MDT
Thank you Colin No i don't have iptables or rules firewalled is stopped selinux disabled as well iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Regards Regards Le lun. 17 mai 2021 à 21:29, Colin Faber a écrit : > Firewall rules dealing with localhost? > > On Mon, May 17, 2021 at 11:33 AM Abdeslam Tahari via lustre-discuss < > lustre-discuss@lists.lustre.org> wrote: > >> Hello >> >> i have a problem to mount the mds/mdt luster, it wont mount at all and >> there is no message errors at the console >> >> -it does not show errors or messages while mounting it >> >> here are some debug file logs >> >> >> i specify it is a new project that i am doing. >> >> the version and packages of luter installed: >> kmod-lustre-2.12.5-1.el7.x86_64 >> kernel-devel-3.10.0-1127.8.2.el7_lustre.x86_64 >> lustre-2.12.5-1.el7.x86_64 >> lustre-resource-agents-2.12.5-1.el7.x86_64 >> kernel-3.10.0-1160.2.1.el7_lustre.x86_64 >> kernel-debuginfo-common-x86_64-3.10.0-1160.2.1.el7_lustre.x86_64 >> kmod-lustre-osd-ldiskfs-2.12.5-1.el7.x86_64 >> kernel-3.10.0-1127.8.2.el7_lustre.x86_64 >> lustre-osd-ldiskfs-mount-2.12.5-1.el7.x86_64 >> >> >> >> the system(os) Centos 7 >> >> the kernel >> Linux lustre-mds1 3.10.0-1127.8.2.el7_lustre.x86_64 >> cat /etc/redhat-release >> >> >> when i mount the luster file-system it wont show up and no errors >> >> mount -t lustre /dev/sda /mds >> >> lctl dl does not show up >> >> df -h no mount point for /dev/sda >> >> >> lctl dl >> >> shows this: >> lctl dl >> 0 UP osd-ldiskfs lustre-MDT-osd lustre-MDT-osd_UUID 3 >> 2 UP mgc MGC10.0.1.70@tcp 57e06c2d-5294-f034-fd95-460cee4f92b7 4 >> 3 UP mds MDS MDS_uuid 2 >> >> >> but unfortunately it disappears after 03 seconds >> >> lctl dl shows nothing >> >> lctl dk >> >> shows this debug output >> >> >> 0020:0080:18.0:1621276062.004338:0:13403:0:(obd_config.c:1128:class_process_config()) >> processing cmd: cf006 >> 0020:0080:18.0:1621276062.004341:0:13403:0:(obd_config.c:1147:class_process_config()) >> removing mappings for uuid MGC10.0.1.70@tcp_0 >> 0020:0104:18.0:1621276062.004346:0:13403:0:(obd_mount.c:661:lustre_put_lsi()) >> put 9bbbf91d5800 1 >> 0020:0080:18.0:1621276062.004351:0:13403:0:(genops.c:1501:class_disconnect()) >> disconnect: cookie 0x256dd92fc5bf929c >> 0020:0080:18.0:1621276062.004354:0:13403:0:(genops.c:1024:class_export_put()) >> final put 9bbf3e66a400/lustre-MDT-osd_UUID >> 0020:0100:18.0:1621276062.004361:0:13403:0:(obd_config.c:2100:class_manual_cleanup()) >> Manual cleanup of lustre-MDT-osd (flags='') >> 0020:0080:18.0:1621276062.004368:0:821:0:(genops.c:974:class_export_destroy()) >> destroying export 9bbf3e66a400/lustre-MDT-osd_UUID for >> lustre-MDT-osd >> 0020:0080:18.0:1621276062.004376:0:13403:0:(obd_config.c:1128:class_process_config()) >> processing cmd: cf004 >> 0020:0080:18.0:1621276062.004379:0:13403:0:(obd_config.c:659:class_cleanup()) >> lustre-MDT-osd: forcing exports to disconnect: 0/0 >> 0020:0008:18.0:1621276062.004382:0:13403:0:(genops.c:1590:class_disconnect_exports()) >> OBD device 0 (9bbf47141080) has no exports >> 0020:0080:18.0:1621276062.004788:0:13403:0:(obd_config.c:1128:class_process_config()) >> processing cmd: cf002 >> 0020:0080:18.0:1621276062.004791:0:13403:0:(obd_config.c:589:class_detach()) >> detach on obd lustre-MDT-osd (uuid lustre-MDT-osd_UUID) >> 0020:0080:18.0:1621276062.004794:0:13403:0:(genops.c:1024:class_export_put()) >> final put 9bbf48800c00/lustre-MDT-osd_UUID >> 0020:0080:18.0:1621276062.004796:0:13403:0:(genops.c:974:class_export_destroy()) >> destroying export 9bbf48800c00/lustre-MDT-osd_UUID for >> lustre-MDT-osd >> 0020:0100:18.0:1621276062.004799:0:13403:0:(genops.c:481:class_free_dev()) >> finishing cleanup of obd lustre-MDT-osd (lustre-MDT-osd_UUID) >> 0020:0104:18.0:1621276062.450759:0:13403:0:(obd_mount.c:605:lustre_free_lsi()) >> Freeing lsi 9bbbf91d6800 >> 0020:0100:18.0:1621276062.450805:0:13403:0:(obd_config.c:2100:class_manual_cleanup()) >> Manual cleanup of
[lustre-discuss] problems to mount MDS and MDT
Hello i have a problem to mount the mds/mdt luster, it wont mount at all and there is no message errors at the console -it does not show errors or messages while mounting it here are some debug file logs i specify it is a new project that i am doing. the version and packages of luter installed: kmod-lustre-2.12.5-1.el7.x86_64 kernel-devel-3.10.0-1127.8.2.el7_lustre.x86_64 lustre-2.12.5-1.el7.x86_64 lustre-resource-agents-2.12.5-1.el7.x86_64 kernel-3.10.0-1160.2.1.el7_lustre.x86_64 kernel-debuginfo-common-x86_64-3.10.0-1160.2.1.el7_lustre.x86_64 kmod-lustre-osd-ldiskfs-2.12.5-1.el7.x86_64 kernel-3.10.0-1127.8.2.el7_lustre.x86_64 lustre-osd-ldiskfs-mount-2.12.5-1.el7.x86_64 the system(os) Centos 7 the kernel Linux lustre-mds1 3.10.0-1127.8.2.el7_lustre.x86_64 cat /etc/redhat-release when i mount the luster file-system it wont show up and no errors mount -t lustre /dev/sda /mds lctl dl does not show up df -h no mount point for /dev/sda lctl dl shows this: lctl dl 0 UP osd-ldiskfs lustre-MDT-osd lustre-MDT-osd_UUID 3 2 UP mgc MGC10.0.1.70@tcp 57e06c2d-5294-f034-fd95-460cee4f92b7 4 3 UP mds MDS MDS_uuid 2 but unfortunately it disappears after 03 seconds lctl dl shows nothing lctl dk shows this debug output 0020:0080:18.0:1621276062.004338:0:13403:0:(obd_config.c:1128:class_process_config()) processing cmd: cf006 0020:0080:18.0:1621276062.004341:0:13403:0:(obd_config.c:1147:class_process_config()) removing mappings for uuid MGC10.0.1.70@tcp_0 0020:0104:18.0:1621276062.004346:0:13403:0:(obd_mount.c:661:lustre_put_lsi()) put 9bbbf91d5800 1 0020:0080:18.0:1621276062.004351:0:13403:0:(genops.c:1501:class_disconnect()) disconnect: cookie 0x256dd92fc5bf929c 0020:0080:18.0:1621276062.004354:0:13403:0:(genops.c:1024:class_export_put()) final put 9bbf3e66a400/lustre-MDT-osd_UUID 0020:0100:18.0:1621276062.004361:0:13403:0:(obd_config.c:2100:class_manual_cleanup()) Manual cleanup of lustre-MDT-osd (flags='') 0020:0080:18.0:1621276062.004368:0:821:0:(genops.c:974:class_export_destroy()) destroying export 9bbf3e66a400/lustre-MDT-osd_UUID for lustre-MDT-osd 0020:0080:18.0:1621276062.004376:0:13403:0:(obd_config.c:1128:class_process_config()) processing cmd: cf004 0020:0080:18.0:1621276062.004379:0:13403:0:(obd_config.c:659:class_cleanup()) lustre-MDT-osd: forcing exports to disconnect: 0/0 0020:0008:18.0:1621276062.004382:0:13403:0:(genops.c:1590:class_disconnect_exports()) OBD device 0 (9bbf47141080) has no exports 0020:0080:18.0:1621276062.004788:0:13403:0:(obd_config.c:1128:class_process_config()) processing cmd: cf002 0020:0080:18.0:1621276062.004791:0:13403:0:(obd_config.c:589:class_detach()) detach on obd lustre-MDT-osd (uuid lustre-MDT-osd_UUID) 0020:0080:18.0:1621276062.004794:0:13403:0:(genops.c:1024:class_export_put()) final put 9bbf48800c00/lustre-MDT-osd_UUID 0020:0080:18.0:1621276062.004796:0:13403:0:(genops.c:974:class_export_destroy()) destroying export 9bbf48800c00/lustre-MDT-osd_UUID for lustre-MDT-osd 0020:0100:18.0:1621276062.004799:0:13403:0:(genops.c:481:class_free_dev()) finishing cleanup of obd lustre-MDT-osd (lustre-MDT-osd_UUID) 0020:0104:18.0:1621276062.450759:0:13403:0:(obd_mount.c:605:lustre_free_lsi()) Freeing lsi 9bbbf91d6800 0020:0100:18.0:1621276062.450805:0:13403:0:(obd_config.c:2100:class_manual_cleanup()) Manual cleanup of MDS (flags='F') 0020:0080:18.0:1621276062.450806:0:13403:0:(obd_config.c:1128:class_process_config()) processing cmd: cf004 0020:0080:18.0:1621276062.450807:0:13403:0:(obd_config.c:659:class_cleanup()) MDS: forcing exports to disconnect: 0/0 0020:0008:18.0:1621276062.450809:0:13403:0:(genops.c:1590:class_disconnect_exports()) OBD device 3 (9bbf43fdd280) has no exports 0020:0080:58.0F:1621276062.490781:0:13403:0:(obd_config.c:1128:class_process_config()) processing cmd: cf002 0020:0080:58.0:1621276062.490787:0:13403:0:(obd_config.c:589:class_detach()) detach on obd MDS (uuid MDS_uuid) 0020:0080:58.0:1621276062.490788:0:13403:0:(genops.c:1024:class_export_put()) final put 9bbf3e668800/MDS_uuid 0020:0080:58.0:1621276062.490790:0:13403:0:(genops.c:974:class_export_destroy()) destroying export 9bbf3e668800/MDS_uuid for MDS 0020:0100:58.0:1621276062.490791:0:13403:0:(genops.c:481:class_free_dev()) finishing cleanup of obd MDS (MDS_uuid) 0020:02000400:58.0:1621276062.490877:0:13403:0:(obd_mount_server.c:1642:server_put_super()) server umount lustre-MDT complete 0400:0202:42.0:1621276086.284109:0:5400:0:(acceptor.c:321:lnet_accept()) 120-3: Refusing connection from 127.0.0.1 for 127.0.0.1@tcp: No matching NI 0800:0002:6.0:1621276086.284152:0:5383:0:(socklnd_cb.c:1817:ksocknal_recv_hello()) Error -104 reading HELLO from 127.0.0.1
