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

[Tom Talpey]

On 12/7/2023 1:32 PM, Jeremy Allison wrote:
> On Thu, Dec 07, 2023 at 05:50:50PM +0000, David Howells wrote:
>> Jeremy Allison <jra at samba.org> wrote:
>>
>>> >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.
>>
>> So just compounding them would leave us in the same situation we are 
>> in now -
>> which would be fine.
>>
>> What do you think about the idea of having the server see a specifically
>> arranged compounded pair and turn them into an op that can't otherwise be
>> represented in the protocol?
> 
> Complex, ugly code. How long does the server wait
> for the second operation before proceeding with
> the first ?

So existing SMB operations do this, but somewhat arbitrarily. An
operation can "go async" in the middle of a compound, by returning
STATUS_PENDING and subsequently completing with a second response.
Some operations pretty much always do this, for example directory
change notifications.

>> Or is it better to try and get the protocol extended?
> 
> If this is a Linux -> Linux op, we have a protocol
> space (the SMB3+POSIX) we can extend without having
> to go via Microsoft. But this would need to be very carefully designed.

True, but as you say, risky as heck. Don't forget the rather large
third-party SMB3 support from other vendors who may or may not be
on board.

I would STRONGLY discourage considering extending compounds in an
attempt to provide atomicity. But, perhaps some super-hairy ioctl-type
request, coupled with persistent session support? Heavy lift.

Tom.