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.
