[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]

https://bugzilla.redhat.com/show_bug.cgi?id=1717824

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> ---
@Susant,

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.



Thanks,
BRs

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