[cifs-protocol] [REG:117031615465515] [MS-SMB2] Question wrt to copy-chunk ioctl

[Bryan Burgin]

[dochelp to bcc]
[+casemail]

Hi Ralph,

Thank you for your question.  We created SR 117031615465515 to track this issue.  An engineer from the protocols team will contact you soon.

Bryan


-----Original Message-----
From: Ralph Böhme [mailto:slow at samba.org] 
Sent: Thursday, March 16, 2017 7:53 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [MS-SMB2] Question wrt to copy-chunk ioctl

Hello dochelp,

while working on a change of the Samba SMB2 server-side copy-chunk implementation I noticed the following.

Previously in Samba the copy-chunk implementation was synchronous wrt to the individual SRV_COPYCHUNK chunks in the SRV_COPYCHUNK_COPY packet. As a result the chunk were copied sequentially maintaining the order from the SRV_COPYCHUNK_COPY packet.

The new implementation will be asynchronous using a threadpool with worker threads to do the IO, scheduling all SRV_COPYCHUNKs of a SRV_COPYCHUNK_COPY packet in parallel, so no ordering guarantees are maintained.

The Samba testsuite contains a copy-chunk test that now fails with the async implementation. The test deliberately crafts a SRV_COPYCHUNK_COPY request that requires ordering:

        /* first chunk overwrites existing dest data */
        cc_copy.chunks[0].source_off = 0;
        cc_copy.chunks[0].target_off = 0;
        cc_copy.chunks[0].length = 4096;

        /* second chunk overwrites the first */
        cc_copy.chunks[1].source_off = 4096;
        cc_copy.chunks[1].target_off = 0;
        cc_copy.chunks[1].length = 4096;

The test verifies the destination file content after the copy-chunk request which will fail if the server doesn't schedule the above chunks in order. So occasionally, depending on timing and thread scheduling in the kernel, this test failed.

I was then running this particular test against a Windows 2016 server hoping it might occasionally fail as well which would have prooved that the server implemeted this asynchronously as well.

Unfortunately after running the test in a loop for quite some time, it never failed, so I can't infer the server implementation.

The async out-of-order copy-chunk behaviour seems to be allowed by MS-SMB2
3.3.5.15.6 "Handling a Server-Side Data Copy Request" which notices:

   ... . If no such locks are found, starting with the first chunk received in
   the Chunks field, the server MUST copy each chunk from the source file to the
   destination file in an implementation-specific manner. ...

So my question is:

what is the expectation here from a protocol perspective and will a real world Windows client ever issue such requests that require ordering ?

Thanks for you help!

Cheerio!
-slow