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

[Paulo Alcantara <pc@manguebit.com>]

Bharath SM <bharathsm.hsk@gmail.com> writes:

> If the file has only deferred handles and a handle lease break occurs,
> closing all the handles triggers an implicit acknowledgment. After the
> last handle is closed, the server may release the structures
> associated with the file handle. If the acknowledgment is sent after
> closing all the handles, the server may ignore it or it may return an
> invalid file error, as it could have already freed the handle/lease
> key and related structures. 

I couldn't find anything in the specs related to the above.  Could you
please point me out to the correct specs or is this just theorical?

Have you been able to reproduce the above?  If so, please share the
details.

If the server is returning an invalid file error for a lease break ack
sent by the client that should be a no-op, isn't that a server bug then?

> Additionally, this would result in an extra command being sent to the
> server. This check was added to avoid this case to send lease break
> ack only when openfilelist is not empty.

I understand.  The problem with attempting to save that extra roundtrip
has caused performance problems with our customers accessing their
Windows Server SMB shares.

> I didn't understand why a client would break 'H' lease on a file if
> "one client writing to a file and other client remained the file's
> parent directory."
> Can you please help sharing more details and exact repro steps.?

mount.cifs //srv/share /mnt/1 -o ...,nosharesock
mount.cifs //srv/share /mnt/2 -o ...,nosharesock
tail -f /dev/null > /mnt/1/dir/foo &
mv /mnt/2/dir /mnt/2/dir2