Am 01.03.16 um 14:40 schrieb Volker Lendecke:
On Wed, Feb 24, 2016 at 11:04:08AM -0800, Jeremy Allison wrote:
Hmmm. We can only test this by causing a Windows read to
take a long time. Any idea how to test this ? Does Win32
have named pipes in the fs we could use for that ? If not
we could test using a program that creates a \\pipe\named_pipe
and then responds slowly... But I don't know if the
timeout replies on np's are the same as in the filesystem.
Just use a USB2 stick.
[MS-SMB2] gives some hints when Windows will send out interim replies:
<296> Section 3.3.5.12: Windows SMB2 servers send an interim response to
the client and handle the read asynchronously if the read is not
finished in 0.5 milliseconds.
<297> Section 3.3.5.12: Windows-based servers handle the following
commands asynchronously: SMB2 Create (section 2.2.13) when this create would
result in an oplock break, SMB2 IOCTL Request (section 2.2.31) for
FSCTL_PIPE_TRANSCEIVE if it blocks for more than 1 millisecond, SMB2 IOCTL
Request for FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE (section
2.2.31)
when oplock break happens, SMB2 Change_Notify Request (section 2.2.35) if
it blocks for more than 0.5 milliseconds, SMB2 Read request (section 2.2.19)
for named pipes if it blocks for more than 0.5 milliseconds,
SMB2 Write request (section 2.2.21) for named pipes if it blocks for more
than 0.5 milliseconds, SMB2 Write Request (section 2.2.21) for large
file write,
SMB2 lock request (section 2.2.26) if the LOCKFLAG_FAIL_IMMEDIATELY flag
is not set,
and SMB2 FLUSH Request (section 2.2.17) for named pipes.
Cheers,
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
