Re: [PATCH] smb: client: fix delay on concurrent opens

[Paulo Alcantara <pc@manguebit.com>]

Shyam Prasad N <nspmangalore@gmail.com> writes:

> I think this version of the patch will be more problematic, as it will
> open up a time window between the lease break ack and the file close.
> Which is why we moved the _cifsFileInfo_put above as it is today.

Can you explain why it would be a problem sending a lease break ack
and then closing the file?

Do you have any reproducers for such problem?

> Specifically, it is still not clear to me what was the exact bug that
> your customer hit. And why is your patch fixing that issue? Can you
> please elaborate on that?

(1) CREATE foo
(2) CREATE resp
(3) CREATE foo
(4) LEASE BREAK (RWH -> RW)
(5) CLOSE foo
(6) CLOSE resp
...30s later...
(7) CREATE resp for (3)

Windows Server is delaying the CREATE request in (3) by 30s because the
client hasn't sent the lease break ack for (4).

Since the client closed the last open handle,
!list_empty(&cinode->openFileList) is obviously false and hence the
lease break ack isn't sent.

Pierguido suggested 'closetimeo=0' to the customer and it seemed to help
them with the performance issues due to delayed opens.

What is your suggestion to get rid of this optimization and then sending
lease break acks regardless whether there are open handles or not?

> On RWH to RW lease break, we would force close all deferred handles.
> But any active handles (that are still kept open by the user) will
> continue to remain open. Which is what this check is about.

The check you're referring to is related to whether or not sending lease
break acks.  What do you mean about "continue to remain open"?