[cifs-protocol] Clarification on expected behavior with SMB2 short reads/writes. [120051422002815]

Obaid Farooqi obaidf at microsoft.com
Thu May 21 19:12:08 UTC 2020


Hi Jeremy:
When you conducted this experiment, what tool on the Windows client you used? 
Also please upload the wireshark trace to the following link:

File Transfer - Case 120051422002815
https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiZjk5NGVkMjEtOGRjMS00Yjc5LTlkMmMtZTgyYTQ5NjU0ZTMzIiwic3IiOiIxMjAwNTE0MjIwMDI4MTUiLCJhcHBpZCI6ImU2ZWU0M2ViLTBmYmMtNDU0Ni1iYzUyLTRjMTYxZmNkZjRjNCIsInN2IjoidjEiLCJycyI6IkV4dGVybmFsIiwid3RpZCI6ImY2Y2ZmNjgwLTdkNmItNGZmNC1iY2I4LTBkODlkZmFmNWVlYiIsImlzcyI6Imh0dHBzOi8vYXBpLmR0bW5lYnVsYS5taWNyb3NvZnQuY29tIiwiYXVkIjoiaHR0cDovL3NtYyIsImV4cCI6MTU5Nzg2Mzk2OSwibmJmIjoxNTkwMDg3OTY5fQ.TCJb-9xWE1RZrXp1GDSp1Unx7yHMhzJ2wRb5GgLQo5EOWIofcdIIKOB4LpOaRHPtcjtJd96_OXfx_WRwLW-o0s3XMWYZ9RReQF2RsJQX8EhNXRhwBPsfUXcAKaIl3wS7hHWDdITCSLLzSs2b0vLSVeMe99oM4xEhS6PL95lkKDQp0p0WJOavfmGALp2P9TDKUAt4Frr28kYeRApGqnUW92udk2cM0s9aySc9UkMGmqPiNHQhIxowOGSXvyxu7M6KgTbur62dPriya3w85-d9AILwq_o63xv8xieNQqO6VEdODx9NHrIauUZO9KyaSzEJjlbszoktVdwyEe-ne1MFpA&wid=f994ed21-8dc1-4b79-9d2c-e82a49654e33


username: 120051422002815_noemail at dtmxfer.onmicrosoft.com
Password: G[+3G99l

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Obaid Farooqi 
Sent: Thursday, May 14, 2020 1:18 PM
To: Jeremy Allison <jra at samba.org>; cifs-protocol <cifs-protocol at lists.samba.org>; Stefan Metzmacher <metze at samba.org>; Bradley Suinn <suinn at apple.com>; Steve French <smfrench at gmail.com>
Cc: support <support at mail.support.microsoft.com>
Subject: RE: Clarification on expected behavior with SMB2 short reads/writes. [120051422002815]

Hi Jeremy:
I'll help you with this issue and will be in touch as soon as I have an answer.

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Obaid Farooqi <obaidf at microsoft.com> 
Sent: Thursday, May 14, 2020 1:16 PM
To: Jeremy Allison <jra at samba.org>; cifs-protocol <cifs-protocol at lists.samba.org>; Stefan Metzmacher <metze at samba.org>; Bradley Suinn <suinn at apple.com>; Steve French <smfrench at gmail.com>
Cc: support <support at mail.support.microsoft.com>
Subject: RE: Clarification on expected behavior with SMB2 short reads/writes. [120051422002815]

Hi Jeremy:
Thanks for contacting Microsoft. I have created a case to track this issue. A member of the open specifications team will be in touch soon.

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Jeremy Allison <jra at samba.org> 
Sent: Thursday, May 14, 2020 12:32 PM
To: cifs-protocol <cifs-protocol at lists.samba.org>; Interoperability Documentation Help <dochelp at microsoft.com>; Stefan Metzmacher <metze at samba.org>; jra at samba.org; Obaid Farooqi <obaidf at microsoft.com>; Bradley Suinn <suinn at apple.com>; Steve French <smfrench at gmail.com>
Subject: [EXTERNAL] Clarification on expected behavior with SMB2 short reads/writes.

Hi Dochelp,

We recently noticed a problem with the Windows (and MacOSX) clients when the server returns short reads.

The MS-SMB2 description of SMB2_READ has the following field inside the read request:

MinimumCount (4 bytes): The minimum number of bytes to be read for this operation to be successful. If fewer than the minimum number of bytes are read by the server, the server MUST return an error rather than the bytes read.

Windows sets this to zero, implying that for a read request of X bytes, a server may optionally return less than X bytes, so long as the number of bytes returned is greater than MinimumCount.

This is expected at end-of-file, when
the server has run out of available bytes to return.

However, the Windows client misbehaves
if this is returned for an SMB2_READ at
an offset in the middle of a file.

The Windows client pipelines reads at
(around) 1MB byte boundaries, and issues as many async simultaneous reads as it has credits for. So for a 1GB file it can simultaneously send (note this is an example only, I have wireshark traces of real behavior):

1). SMB2_READ offset 0 length 1MB
2). SMB2_READ offset 1MB length 1MB
3). SMB2_READ offset 2MB length 1MB
..
X). SMB2_READ offset (X-1)MB length 1MB

Consider if the server returns a read
return value of 1MB-2 bytes for the
(1) read (the one at offset 0).

Linux cifsfs and the libsmbclient Samba
library check the short read return value, and will re-issue a read at offset 1MB-2 length 2 bytes to fill in the missing data.

The Windows client doesn't treat the short read reply at (1) as EOF, and doesn't re-issue a read for the missing 2 bytes, ending up with data corruption in the copied file.

If this is expected behavior, I think either the protocol doc needs updating to prohibit short reads (and probably writes too) or a Windows behavior note adding explaining that Windows clients cannot cope with short SMB2_READ / SMB2_WRITE replies (execpt for EOF/EIO or DISK_FULL/EIO cases).

Thanks,

Jeremy Allison,
Samba Team.




More information about the cifs-protocol mailing list