[cifs-protocol] [EXTERNAL] SMB3 ODX Block Aligment: Rounding Up vs Down - TrackingID#2107080040005603

[Jeff McCashland]

[DocHelp to BCC, support on CC, SR ID on Subject]

Hi Ralph,

Thank you for your question. We have created SR 2107080040005603 to track this issue. One of our engineers will respond soon. 

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
We value your feedback.  My manager is Natesha Morrison (namorri), +1 (704) 430-4292

-----Original Message-----
From: Ralph Boehme <slow at samba.org> 
Sent: Thursday, July 8, 2021 11:04 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [EXTERNAL] SMB3 ODX Block Aligment: Rounding Up vs Down

Hello dochelp,

I'm trying to implement SMB3 ODX in Samba, but I'm having a hard time understanding 2.1.5.9.20 FSCTL_OFFLOAD_READ.

Following the spec by the letter to me it seems the client will not be able to do a full file copy.

The problem is this clause:

If the sum of InputBuffer.FileOffset and InputBuffer.CopyLength is greater than ValidDataLength:

- Set InputBuffer.CopyLength to ValidDataLength-InputBuffer.FileOffset.

- If VdlSameAsEof is TRUE:

   - Set InputBuffer.CopyLength to
     BlockAlignTruncate(InputBuffer.CopyLength,...LogicalBytesPerSector).

   - Set VdlTrimmedCopyLength to InputBuffer.CopyLength.

   - Set OutputBuffer.Flags to
     OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE.

- EndIf

EndIf

I've implemented this as is which results in an incomplete copy. The attached pcap ODX-bad-block-align-truncate.pcapng.gz contains an ODX copy of a file of size 1 MB + 2 bytes.

In this example VdlSameAsEof will be TRUE and LogicalBytesPerSector is 4096.

Due to the

     Set InputBuffer.CopyLength to
     BlockAlignTruncate(InputBuffer.CopyLength,...LogicalBytesPerSector).

the first ODX READ is block aligned rounded down to 1 MB (p.122, TransferLength=1Mb). The subsequent ODX WRITE writes this 1 MB.

Now the client sends another ODX READ with Offset=1MB and CopyLenght=1MB and this time gets rounded down to 0 as per

     Set InputBuffer.CopyLength to
     BlockAlignTruncate(InputBuffer.CopyLength,...LogicalBytesPerSector).

The ODX READ response in p.126 therefor contains TransferLength=0. 
Subsequently the client doesn't issue further ODX WRITEs to write the remaining range.

Now, as soon as I change the algorithm from

     Set InputBuffer.CopyLength to
     BlockAlignTruncate(InputBuffer.CopyLength,...LogicalBytesPerSector).

to

     Set InputBuffer.CopyLength to
     BlockAlign(InputBuffer.CopyLength,...LogicalBytesPerSector).

ie use BlockAlign() instead of BlockAlignTruncate(), iow rounding up instead of down I see a complete copy. ODX-good-block-align.pcapng.gz contains a trace of a copy of the same file (1MB + 2 bytes).

I've also looked at the sources of the ODX implementation in the Illumos kernel SMB server and indeed it uses "rounding up" instead of down approach too:

<https://github.com/Nexenta/illumos-nexenta/blob/release-5.3/usr/src/uts/common/fs/smbsrv/smb2_fsctl_odx.c#L285>

   src_rnd_size = (src_size + OFFMASK) & ~OFFMASK;

Can you please verify my findings if either MS-FSA has a bug here or if possible misunderstanding something in the spec?

Thanks a lot!

Cheers!
-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team       https://www.sernet.de/en/team-samba
Samba Development and Support, SerNet Professional Services
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WinZip Compressed Attachments.zip
Type: application/x-zip-compressed
Size: 409517 bytes
Desc: WinZip Compressed Attachments.zip
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20210708/b601c09a/WinZipCompressedAttachments.bin>