[LU-6730] conf-sanity test_45: FAIL: manual_umount_client failed

• Type: Bug
• Resolution: Duplicate
• Priority: Critical
• Affects Version/s: Lustre 2.8.0
• Environment: Lustre Build: https://build.hpdd.intel.com/job/lustre-master/3026; Distro/Arch: RHEL6.6/x86_64; FSTYPE=zfs
• Severity: 3
• Assignee: Jian Yu
• Reporter: Jian Yu

Description

conf-sanity test 45 failed as follows:

manual umount lustre on /mnt/lustre....
CMD: onyx-35vm6.onyx.hpdd.intel.com umount -d --force /mnt/lustre
umount2: Device or resource busy
umount: /mnt/lustre: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
umount2: Device or resource busy
 conf-sanity test_45: @@@@@@ FAIL: manual_umount_client failed 
df: `/mnt/lustre': Cannot send after transport endpoint shutdown
df: no file systems processed

Maloo report: https://testing.hpdd.intel.com/test_sets/af77cd58-fa4f-11e4-828f-5254006e85c2

Issue Links

• duplicates: LU-1882 conf-sanity test_45: umount2: Device or resource busy

Comments

[Jian Yu]

Jian Yu ([e-mail]) uploaded a new patch: http://review.whamcloud.com/15702
Subject: LU-6730 tests: fix fail_loc code in conf-sanity test 45

The above patch didn't fix the unmounting busy issue. The real fix is in LU-1882. The changes in the above patch will be incorporated into the one for that ticket.

[Saurabh Tandan (Inactive)]

Another instance found for interop - 2.7.1 Server/EL6.7 Client, tag 2.7.90.
https://testing.hpdd.intel.com/test_sessions/f371534e-d573-11e5-bc47-5254006e85c2

[Saurabh Tandan (Inactive)]

Server: 2.5.5, b2_5_fe/62
Client: Master, Build# 3266, Tag 2.7.64
https://testing.hpdd.intel.com/test_sets/9bff0100-a04a-11e5-a33d-5254006e85c2

[Gerrit Updater]

Jian Yu ([e-mail]) uploaded a new patch: http://review.whamcloud.com/15702
Subject: LU-6730 tests: fix fail_loc code in conf-sanity test 45
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b7efc2f16c59ab508c5365e5c781862524255980

[Andreas Dilger]

I see the following code in ptlrpc_check_set() but according to the client console logs the fail_loc is being hit repeatedly:

                        /* Turn fail_loc off to prevent it from looping forever. */
                        if (OBD_FAIL_CHECK(OBD_FAIL_PTLRPC_LONG_REPL_UNLINK)) {
                                OBD_FAIL_CHECK_ORSET(OBD_FAIL_PTLRPC_LONG_REPL_UNLINK,
                                                     OBD_FAIL_ONCE);
                        }

Should the test be using 0x80000503 (FAIL_ONCE) so that it eventually finishes?

[Andreas Dilger]

Note: if there is a patch for this ticket, the fail_loc OBD_FAIL_PTLRPC_LONG_UNLINK has been renamed to OBD_FAIL_PTLRPC_LONG_REPL_UNLINK and should be fixed in the test.