[cifs-protocol] [REG:112120310051084] FSCTL_SRV_COPYCHUNK overlapping ranges

[Obaid Farooqi]

Hi David:
I have created a case to track this issue. A member of the open specification team will be in touch to further assist you soon.

Regards,
Obaid Farooqi
Escalation Engineer | Microsoft

Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com


-----Original Message-----
From: David Disseldorp [mailto:ddiss at suse.de]
Sent: Monday, December 03, 2012 6:48 AM
To: Interoperability Documentation Help; cifs-protocol at cifs.org; pfif at tridgell.net
Subject: FSCTL_SRV_COPYCHUNK overlapping ranges

Hi DocHelp,

FSCTL_SRV_COPYCHUNK requests may refer to overlapping file ranges. The handling of such requests is currently unclear from the documentation in [MS-SMB2] 3.3.5.15.6 Handling a Server-Side Data Copy Request.

I've outlined two such cases below, where the subsequent on disk state is dependent on specific server behaviour.

1) An FSCTL_SRV_COPYCHUNK request includes two chunks (SRV_COPYCHUNK
   records), where both specify a target range which overlaps with the
   other.

Initial State
-------------
	File:		src		dest
	Offset:		01234567	01234567
	Data:		ABCDEFGH	abcdefgh

Request
-------
	FSCTL_SRV_COPYCHUNK(dest)
	SourceKey = SRV_REQUEST_RESUME_KEY(src)
	ChunkCount = 2
	Chunks[0].SourceOffset = 0
	Chunks[0].TargetOffset = 0
	Chunks[0].Length = 4
	Chunks[1].SourceOffset = 4
	Chunks[1].TargetOffset = 0
	Chunks[1].Length = 4

Resultant State
---------------
	File:		src		dest
	Offset:		01234567	01234567
	Data:		ABCDEFGH	EFGHefgh

The resultant contents of dest is dependent on the order in which the chunks are processed. In the above example, Chunks[0] is written to disk before Chunks[1]. If the server where to process Chunks[1] before Chunks[0], then the resultant data would be ABCDefgh. If the server where to dispatch both both IOs simultaneously (asynchronously) the resultant data would be undefined.

Windows (tested against Server 2008 & 2012) appears to always process chunks sequentially, starting at Chunks[0] and working its way up.

Is this order of processing required, such that a chunk with a higher index must overwrite data from chunks with a lesser array index?


2) An FSCTL_SRV_COPYCHUNK request includes a single chunk, where the
   source and target ranges overlap, and the SourceKey refers to the
   same target file.

Initial State
-------------
	File:		src_and_dest
	Offset:		0123456789
	Data:		abcdefghij

Request
-------
	FSCTL_SRV_COPYCHUNK(src_and_dest)
	SourceKey = SRV_REQUEST_RESUME_KEY(src_and_dest)
	ChunkCount = 1
	Chunks[0].SourceOffset = 0
	Chunks[0].TargetOffset = 4
	Chunks[0].Length = 6

Resultant State
---------------
	File:		src_and_dest
	Offset:		0123456789
	Data:		abcdabcdef

The resultant contents of src_and_dest is dependent on the server's copy algorithm. In the above example, the server uses an IO buffer large enough to hold the entire six-byte source data before writing to TargetOffset. If the server were to use a four-byte IO buffer and started reads/writes from the lowest offset, then the two overlapping bytes in the above example would be overwritten before being read. The resultant file contents would be abcdabcdab.

Windows 2008r2 appears to use a 2048 byte copy buffer, overlapping bytes after this offset are written before being read. Windows 2012 on the other hand appears to use a buffer large enough to hold its maximum supported chunk size (1M).

Does Windows make any guarantees on what data will end up on disk when such a copychunk source/target overlap exists?

Regards, David
Microsoft is committed to protecting your privacy.  Please read the Microsoft Privacy Statement for more information.The above is an email for a support case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE casemail at microsoft.com IN YOUR REPLY if you want your response added to the case automatically. For technical assistance, please include the Support Engineer on the TO: line. Thank you.