Re: [PATCH v2 3/9] smb/client: handle smb2_set_sparse() failure in EOF-extending fallocate

[hehuiwen <huiwen.he@linux.dev>]

Hi Steve,

I I agree with your point. On local filesystems such as ext4, XFS and 
btrfs,fallocate can reserve space for the requested range, including a 
range beyond EOF, while leaving other holes in the file untouched.

However, patches 3 and 4 do not introduce new clear-sparse cases. They 
only stop ignoring errors from the existing smb2_set_sparse(..., false) 
calls. In the paths where CIFS still relies on FSCTL_SET_SPARSE to 
provide the preallocation guarantee, failure from that operation should 
fail fallocate; otherwise we can return success while the requested 
range may remain sparse.

But you reminded me to rethink two related questions:

1.Is clearing the SMB sparse attribute a reasonable approximation for 
Linux fallocate semantics in some limited cases? Linux fallocate is
byte-range based, while FSCTL_SET_SPARSE is a file-level operation,
so it may not be a good fit as a general range allocation mechanism.

2.If that approximation is acceptable only for limited cases, are all
current fallocate paths that use smb2_set_sparse(..., false) actually 
safe? In other words, do we need to tighten the current cases where
CIFS relies on clearing the sparse attribute to emulate fallocate?

I will check the current code paths more carefully and make sure the all
operations are actually safe, assuming that clearing the sparse 
attribute can be used to approximate fallocate semantics in some limited 
cases.

I would be glad to hear your thoughts on this.

Thanks,
Huiwen


在 2026/6/25 05:26, Steve French 写道:
> So presumably I should skip patches 3 and 4 since it is allowed to have a
> sparse file which has allocated beyond end of file, and also allowed to
> have a falloc in a file that has holes - so we shouldn't be failing
> fallocate just because clearing sparse bit fails. Any thoughts?
> 
> On Tue, Jun 23, 2026 at 11:05 PM hehuiwen <huiwen.he@linux.dev> wrote:
> 
>> Hi Steve,
>>
>> Yes, that is possible. I checked ext4, XFS and btrfs with examples like:
>>
>>           truncate -s 1M file
>>           fallocate -n -o 2M -l 1M file
>>           filefrag -v file
>>
>> and:
>>
>>           truncate -s 1M file
>>           fallocate -o 2M -l 1M file
>>           filefrag -v file
>>
>> With FALLOC_FL_KEEP_SIZE, the file size stays at 1M while the range
>> [2M, 3M) is preallocated. Without FALLOC_FL_KEEP_SIZE, the file size
>> grows to 3M, but the filesystems still only allocate the requested
>> range [2M, 3M). Holes before that range are not removed.
>>
>> Patch 3 only changes the error handling around the existing
>> smb2_set_sparse(..., false) call. I agree that clearing the sparse
>> attribute is not a general byte-range allocation mechanism.
>>
>> Patch 9 handles the sparse EOF-adjacent case differently: small ranges
>> are allocated by writing zeroes only to the requested range, and larger
>> ranges remain unsupported. That avoids clearing the sparse attribute
>> for this case.
>>
>> Thanks,
>> Huiwen
>>
>>
>> 在 2026/6/24 10:48, Steve French 写道:
>>> Would it be possible in Linux to have a sparse file but still with
>>> space reserved beyond end of file?  In other words are there cases
>>> where you could have a file with holes in it in Linux which still
>>> fallocated beyond end of file.  What happens to ext4, xfs, btrfs if
>>> you try that?  Does fallocate beyond of file remove all holes in a
>>> (sparse) file?
>>
>>
>