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

[Kristian Smith]

[Moving Jeff to BCC]

Hi Ralph,

I'll be your point of contact for this issue moving forward. I will reach out to you once I've investigated your proposed SMB issue and have more information.

Thanks for reaching out.
-Kristian

Kristian Smith
Support Escalation Engineer
Windows Open Spec Protocols
Office: (425) 421-4442
krsmith at microsoftsupport.com 



-----Original Message-----
From: Jeff McCashland <jeffm at microsoft.com> 
Sent: Thursday, July 8, 2021 11:37 AM
To: Ralph Boehme <slow at samba.org>
Cc: cifs-protocol at lists.samba.org; Jeff McCashland <jeffm at microsoftsupport.com>
Subject: RE: [EXTERNAL] SMB3 ODX Block Aligment: Rounding Up vs Down - TrackingID#2107080040005603

[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: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=04%7C01%7CKristian.Smith%40microsoft.com%7Cbca642430dc24280b64908d9423f648f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637613662319930004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MO0fTDkD8Z9CLrjHC8v34luSkMxLUz7E4qvSFuj9GuU%3D&reserved=0 | 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNexenta%2Fillumos-nexenta%2Fblob%2Frelease-5.3%2Fusr%2Fsrc%2Futs%2Fcommon%2Ffs%2Fsmbsrv%2Fsmb2_fsctl_odx.c%23L285&data=04%7C01%7CKristian.Smith%40microsoft.com%7Cbca642430dc24280b64908d9423f648f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637613662319930004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hfhq8QJwcYAf8fptYChhIcESCfJnxW1UUIvtsNRRDto%3D&reserved=0>

   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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F&data=04%7C01%7CKristian.Smith%40microsoft.com%7Cbca642430dc24280b64908d9423f648f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637613662319930004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DU5ICsYA8pDcmxHPVnRiTG93txLiVtH3%2FsnGmeIgARc%3D&reserved=0
SerNet Samba Team       https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sernet.de%2Fen%2Fteam-samba&data=04%7C01%7CKristian.Smith%40microsoft.com%7Cbca642430dc24280b64908d9423f648f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637613662319930004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vXusK9Edu3dX6feZbCv4tq2HtNik6OoX9lY2K7RWf84%3D&reserved=0
Samba Development and Support, SerNet Professional Services