Project

General

Profile

Bug #9619

SMB operations by some applications with windows 7 clients take an absurdly long time to respond when oplock is enabled

Added by Adam Stylinski about 2 years ago. Updated 8 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
cifs - CIFS server and client
Start date:
2018-06-19
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

This bug appears to happen in Excel and Word, with Microsoft Security Essentials installed. Microsoft's SMB implementation appears unaffected, and simply disabling oplock, as suggested by this thread (and the linked threads within) seems to eliminate the issue entirely:

https://serverfault.com/questions/799295/omnios-zfs-windows-7-save-as-from-within-applications-lags-5-seconds-for-all

History

#1

Updated by Andrew Stormont 9 months ago

I suspect this is related to the hangs and timeouts we see when running the Windows Protocol Test Suites against our SMB stack.

#2

Updated by Gordon Ross 8 months ago

We had this problem (long ago) in our product. The reason for the delay was that the Windows client was failing to respond to an oplock break request (like an NFS cache delegation recall). We opened a case with MS and found that Windows has a minor defect exposed with old-style oplocks (and not exposed with leases) where oplock break request processing on the client may be blocked while another open on the same object is in progress. The advice from MS was basically, "Well, aren't you planning to implement leases?" and that's what we did.

SMB2 leases are there since #11016 integrated. With that integrated, I don't believe this issue is reproducible anymore.
Anyone mind if we just close this? If on the other hand this IS still reproducible, please provide a network capture.

#3

Updated by Gordon Ross 8 months ago

  • Status changed from New to Feedback
  • Assignee set to Gordon Ross
#4

Updated by Andrew Stormont 8 months ago

Go for it.

Also available in: Atom PDF