[LU-14183] broken ldlm_add_waiting_lock usage Created: 04/Dec/20  Updated: 11/Oct/22  Resolved: 16/Mar/21

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.15.0

Type: Bug Priority: Major
Reporter: Vitaly Fertman Assignee: Vitaly Fertman
Resolution: Fixed Votes: 0
Labels: None

Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

exp_bl_lock_at accounted the period since BLAST send until cancel RPC came to server originally. LU-6032 started to update l_blast_sent for expired locks which are still busy - prolonged locks when the timeout expired. In fact, this is a good idea to cover not the whole period but until any involved RPC comes - it avoids excessively large lock callback timeouts - and the IO which does the lock prolong is also able to re-start the AT cycle by updating the l_blast_sent.

Unfortunately, the change seems to be made occasionally as the main prolong code was not adjusted accordingly.



 Comments   
Comment by Gerrit Updater [ 04/Dec/20 ]

Vitaly Fertman (vitaly.fertman@hpe.com) uploaded a new patch: https://review.whamcloud.com/40868
Subject: LU-14183 ldlm: wrong ldlm_add_waiting_lock usage
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 809eb97a1f8e1b5ca9394c2de18bfdbfcd637013

Comment by Gerrit Updater [ 16/Mar/21 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/40868/
Subject: LU-14183 ldlm: wrong ldlm_add_waiting_lock usage
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: af07c9a79e263f940fea06a911803097b57b55f4

Comment by Peter Jones [ 16/Mar/21 ]

Landed for 2.15

Generated at Sat Feb 10 03:07:33 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.