Re: [PATCH v8 5/5] smb/client: refresh allocation after EOF-extending fallocate

Hi Paulo and Steve，

The current patch series does introduce this regression because it adds 
real server-side allocation for EOF-extending fallocate.

I reproduced the failure using Paulo's reproducer and got the following 
results:

   Samba strict allocate + 15G XFS    -> ENOSPC
   Samba strict allocate + 15G Btrfs  -> PASS
   ksmbd                 + 15G XFS    -> PASS

Samba handles the requests as follows:

   SetAllocation -> fallocate(KEEP_SIZE, 0, 8G)
   SetEOF        -> fallocate(0, 0, 8G)

On XFS, the first call allocates 8 GiB. The second call tries to
reserve nearly 8 GiB again before checking the existing extents,
so it fails with ENOSPC.

ksmbd does not have this problem:

   SetAllocation -> fallocate(KEEP_SIZE, 0, 8G)
   SetEOF        -> truncate(8G)

This appears to be an interaction between Samba strict allocation and
XFS. Since SetAllocation has already allocated the range, fixing Samba
to avoid the second allocation seems more appropriate. What do
you think?

Thanks,
Huiwen

在 2026/7/30 10:17, hehuiwen 写道:
> Hi Paulo,
> 
> Thanks for the report.
> 
> The generic/103 failure is expected because it allocates almost all free 
> space. Using separate filesystems for the test and scratch shares avoids 
> it.
> 
> I have reproduced the generic/590 failure and am investigating it.
> 
> Thanks,
> Huiwen
> 
> 
> 在 2026/7/30 06:54, Paulo Alcantara 写道:
>> Huiwen He <[email protected]> writes:
>>
>>> From: Huiwen He <[email protected]>
>>>
>>> Before this change, xfstests generic/496 was not supported on ksmbd:
>>>
>>>          generic/496 ... [not run] fallocated swap not supported here
>>>
>>> ksmbd handles SetEOF as truncate, so EOF extension alone does not
>>> allocate backing blocks. A fallocated swapfile can therefore still
>>> look sparse to swapon.
>>>
>>> Request allocation for EOF-extending fallocate ranges that can be
>>> represented by FILE_ALLOCATION_INFORMATION, and refresh the allocation
>>> state afterwards.
>>>
>>> With this change, xfstests generic/496 and generic/701 pass on ksmbd.
>>>
>>> However, Samba "strict allocate = no" now exposes the real generic/701
>>> failure: the old pass came from inflated local i_blocks, not from
>>> server allocation. generic/213 also fails in that case because an
>>> oversized allocation request may not return ENOSPC.
>>>
>>> Signed-off-by: Huiwen He <[email protected]>
>>> Reviewed-by: ChenXiaoSong <[email protected]>
>>
>> This patch regressed fstests generic/103 and generic/590 against samba
>> 4.24 (strict allocate = yes) with a 15G xfs partition for both test and
>> scratch shares.  The tests now fail with -ENOSPC.
>>
>> A simple reproducer
>>
>>     $ mount.cifs //samba-fs0/scratch2 /mnt/1 -o username=xxx,password=yyy
>>          $ df -h /mnt/1
>>     Filesystem            Size  Used Avail Use% Mounted on
>>     //samba-fs0/scratch2   15G  326M   15G   3% /mnt/1
>>     $ xfs_io -c "falloc 0 8G" -f /mnt/1/file
>>     fallocate: No space left on device
>