[Bugs] [Bug 1717824] Fencing: Added the tcmu-runner ALUA feature support but after one of node is rebooted the glfs_file_lock() get stucked

bugzilla at redhat.com bugzilla at redhat.com
Tue Jul 23 02:44:00 UTC 2019


Xiubo Li <xiubli at redhat.com> changed:

           What    |Removed                     |Added
              Flags|                            |needinfo?(spalai at redhat.com
                   |                            |)

--- Comment #12 from Xiubo Li <xiubli at redhat.com> ---

There 2 issues are found:

1, From my test the glfs_file_lock() sometimes it will takes around 43 seconds,
is it normal ? And why ?

 90456 2019-07-23 10:08:57.444 31411 [INFO] tcmu_glfs_lock:901 glfs/block0:
lxb--------------glfs_file_lock start
 319959 2019-07-23 10:09:40.183 31411 [INFO] tcmu_glfs_lock:905 glfs/block0:
lxb--------------glfs_file_lock end

2, After the lock is broke and all the FIOs callback will return -1, the
-EPERM, not the -EBUSY as we discussed before. Is there any change about the
return value ? I am only checking the -EBUSY and -ENOTCONN then only after that
the lock state in local tcmu node will be changed. Or the local state in
tcmu-runner service will always in LOCKED state, but it actually already lost
the lock and should be in UNLOCKED state, so all the IOs will fail.


You are receiving this mail because:
You are on the CC list for the bug.

More information about the Bugs mailing list