<div dir="ltr"><span style="color:rgb(80,0,80)">&gt;&gt;    Right. But if there are simultaneous access to the same file from</span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
    any other client and rebalance process, delegations shall not be<br>
    granted or revoked if granted even though they are operating at<br>
    different offsets. So if you rely only on delegations, migration may<br>
    not proceed if an application has held a lock or doing any I/Os.<br>
<br>
<br>
Does the brick process wait for the response of delegation holder<br>
(rebalance process here) before it wipes out the delegation/locks? If<br>
that&#39;s the case, rebalance process can complete one transaction of<br>
(read, src) and (write, dst) before responding to a delegation recall.<br>
That way there is no starvation for both applications and rebalance<br>
process (though this makes both of them slower, but that cannot helped I<br>
think).<br>
</div></div></blockquote>
<br>
yes. Brick process should wait for certain period before revoking the delegations forcefully in case if it is not returned by the client. Also if required (like done by NFS servers) we can choose to increase this timeout value at run time if the client is diligently flushing the data.</blockquote><div><br></div><div style="">hmm.. I would prefer an infinite timeout. The only scenario where brick process can forcefully flush leases would be connection lose with rebalance process. The more scenarios where brick can flush leases without knowledge of rebalance process, we open up more race-windows for this bug to occur.</div><div style=""><br></div><div style="">In fact at least in theory to be correct, rebalance process should replay all the transactions that happened during the lease which got flushed out by brick (after re-acquiring that lease). So, we would like to avoid any such scenarios.</div><div style=""><br></div><div style="">Btw, what is the necessity of timeouts? Is it an insurance against rogue clients who won&#39;t respond back to lease recalls?</div></div>
</div></div>