[LU-7442] conf-sanity test_41c: @@@@@@ FAIL: unexpected concurent MDT mounts rc=17 rc2=0

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.9.0
• Affects Version/s: Lustre 2.8.0
• Environment: single node setup
• Severity: 3
• Assignee: Bruno Faccini (Inactive)
• Reporter: hemaharish

Description

modules unloaded.
error: set_param: /proc/

{fs,sys}/{lnet,lustre}/fail_loc: Found no match
Starting mds1: -o rw,user_xattr /dev/vdb /mnt/mds1
mount.lustre: set /sys/block/vdb/queue/max_sectors_kb to 2147483647

error: set_param: /proc/{fs,sys}

/

{lnet,lustre}

/fail_loc: Found no match
Starting mds1: -o rw,user_xattr /dev/vdb /mnt/mds1
mount.lustre: set /sys/block/vdb/queue/max_sectors_kb to 2147483647

mount.lustre: mount /dev/vdb at /mnt/mds1 failed: File exists
Start of /dev/vdb on mds1 failed 17
Started lustre-MDT0000
Stopping /mnt/mds1 (opts:-f) on fre819
conf-sanity test_41c: @@@@@@ FAIL: unexpected concurent MDT mounts result, rc=17 rc2=0

Issue Links

• is related to: LU-5921 conf-sanity test_41c: unexpected concurent OST mounts result, rc=0 rc2=1

Comments

[Peter Jones]

Landed for 2.9

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/17301/
Subject: LU-7442 tests: Load modules on MDS/OSS in conf-sanity test_41c
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 3973c51b0ba246fb9904235206e6b9269d670a51

[nasf (Inactive)]

Thanks Bruno. I have rebased my patch against the patch http://review.whamcloud.com/#/c/17427 to resolve conf-sanity test_41c failure.

[Bruno Faccini (Inactive)]

hemaharish,
Sorry to be late on this, but am I right if I think that you can encounter this problem solid (I mean the missing load_modules) when you run conf-sanity/test_41c as a single test run and not as part as full conf-sanity test suite ??

[hemaharish]

Yes, failure was permanent on single node setup without patch.

[Bruno Faccini (Inactive)]

The reason of the failure (in fact the non-permanent failure!) is still a bit mysterious for me, but patch re-loading of modules after cleanup is harmless and will clear any special cases...
Just for my information, was this failure permanent during you testing ?