Can fallocate() ops be emulated better using SMB request compounding?

[Jeremy Allison]

On Thu, Dec 07, 2023 at 03:58:46PM +0000, David Howells wrote:
>Hi Steve, Namjae, Jeremy,
>
>At the moment certain fallocate() operations aren't very well implemented in
>the cifs filesystem on Linux, either because the protocol doesn't fully
>support them or because the ops being used don't also set the EOF marker at
>the same time and a separate RPC must be made to do that.
>
>For instance:
>
> - FALLOC_FL_ZERO_RANGE does some zeroing and then sets the EOF as two
>   distinctly separate operations.  The code prevents you from doing this op
>   under some circumstances as it doesn't have an oplock and doesn't want to
>   race with a third party (note that smb3_punch_hole() doesn't have this
>   check).
>
> - FALLOC_FL_COLLAPSE_RANGE uses COPYCHUNK to move the file down and then sets
>   the EOF as two separate operations as there is no protocol op for this.
>   However, the copy will likely fail if the ranges overlap and it's
>   non-atomic with respect to a third party.
>
> - FALLOC_FL_INSERT_RANGE has the same issues as FALLOC_FL_COLLAPSE_RANGE.
>
>Question: Would it be possible to do all of these better by using compounding
>with SMB2_FLAGS_RELATED_OPERATIONS?  In particular, if two components of a
>compound are marked related, does the second get skipped if the first fails?

Yes:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/46dd4182-62d3-4e30-9fe5-e2ec124edca1

"When the current operation requires a FileId and the previous operation
either contains or generates a FileId, if the previous operation fails
with an error, the server SHOULD<253> fail the current operation with
the same error code returned by the previous operation."

>Further, are the two ops then essentially done atomically?

No. They are processed (at least in Samba) as two separate
requests and can be raced by local or other remote access.