From: hehuiwen <huiwen.he@linux.dev>
To: Steve French <smfrench@gmail.com>
Cc: linkinjeon@kernel.org, pc@manguebit.org,
ronniesahlberg@gmail.com, sprasad@microsoft.com, tom@talpey.com,
bharathsm@microsoft.com, senozhatsky@chromium.org,
dhowells@redhat.com, metze@samba.org, chenxiaosong@kylinos.cn,
linux-cifs@vger.kernel.org
Subject: Re: [PATCH v4 0/7] smb/client: fix fallocate and allocation accounting
Date: Mon, 29 Jun 2026 10:14:41 +0800 [thread overview]
Message-ID: <93d481fc-15d4-48c9-961a-3253200ece80@linux.dev> (raw)
In-Reply-To: <CAH2r5mtzjPHuAvko1zSW65DeOcX8KmQJuvy5b4RGxCAm0=4yqA@mail.gmail.com>
Hi Steve,
After looking at this more, I think the key issue is not only which
xfstests pass, but whether we need to implement real fallocate(mode=0)
preallocation semantics in the CIFS client.
For fallocate(mode=0), CIFS currently relies on SetEOF in some paths.
SetEOF only changes the logical file size and does not request real
space allocation from the server.
For servers that can actually preallocate space, such as Samba with
`strict allocate=yes` or ksmbd, the client probably needs to use the
SMB allocation request and update i_blocks from server-reported
AllocationSize.
So I think we may need to separate two topics:
1. preserving Samba `strict allocate=no` compatibility;
2. implementing real fallocate preallocation semantics when the
server supportsit.
However, these two goals can conflict in some tests. For example,
generic/228 expects `falloc 0 50m` to succeed, which matches the old
Samba `strict allocate=no` behavior, while generic/496 needs a
fallocated swapfile to have real allocated blocks, which requires
server-side allocation.
So using FILE_ALLOCATION_INFORMATION without verifying the resulting
AllocationSize may preserve compatibility, but it would still not
guarantee real fallocate preallocation semantics.
Thanks,
Huiwen
在 2026/6/28 02:13, Steve French 写道:
> With all patches (including smb/client: preserve errors from
> smb2_set_sparse) except
> smb/client: verify allocation after EOF-extending fallocate
> tests 496 and 701 fail
>
> On Sat, Jun 27, 2026 at 1:06 PM Steve French <smfrench@gmail.com> wrote:
>>
>> Everything passes with six of these seven as long as I leave out:
>>
>> smb/client: verify allocation after EOF-extending fallocate
>>
>> and revert the earlier patch:
>>
>> smb/client: preserve errors from smb2_set_sparse()
>>
>> On Fri, Jun 26, 2026 at 8:47 AM Huiwen He <huiwen.he@linux.dev> wrote:
>>>
>>> From: Huiwen He <hehuiwen@kylinos.cn>
>>>
>>> Changes in v4:
>>>
>>> - Add new patch 1 to refresh i_blocks after successful duplicate-extents.
>>> This fixes stale st_blocks after reflink and avoids the generic/370
>>> swapon hole-check regression.
>>>
>>> The following patches from v2 have already been merged into cifs-2.6.git for-next:
>>> - smb/client: do not account EOF extension as allocation
>>> - smb/client: preserve errors from smb2_set_sparse()
>>> - smb/client: name the default fallocate mode
>>>
>>> Link to v3:
>>> https://lore.kernel.org/linux-cifs/20260625160154.104450-1-huiwen.he@linux.dev
>>>
>>> Link to v2:
>>> https://lore.kernel.org/linux-cifs/20260624021550.1548952-1-huiwen.he@linux.dev
>>>
>>> Thanks,
>>> Huiwen
>>>
>>> Huiwen He (7):
>>> smb/client: refresh allocation size after duplicate extents
>>> smb/client: handle smb2_set_sparse() failure in EOF-extending
>>> fallocate
>>> smb/client: handle smb2_set_sparse() failure in non-extending
>>> fallocate
>>> smb/client: handle overlapping allocated ranges in fallocate
>>> smb/client: reduce fallocate zero buffer allocation
>>> smb/client: emulate small mode 0 fallocate ranges at or past EOF
>>> smb/client: verify allocation after EOF-extending fallocate
>>>
>>> fs/smb/client/smb2ops.c | 169 +++++++++++++++++++++++++++++++++-----
>>> fs/smb/client/smb2pdu.c | 19 +++++
>>> fs/smb/client/smb2proto.h | 3 +
>>> fs/smb/common/fscc.h | 5 ++
>>> 4 files changed, 175 insertions(+), 21 deletions(-)
>>>
>>> --
>>> 2.43.0
>>>
>>
>>
>> --
>> Thanks,
>>
>> Steve
>
>
>
prev parent reply other threads:[~2026-06-29 2:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 13:47 [PATCH v4 0/7] smb/client: fix fallocate and allocation accounting Huiwen He
2026-06-26 13:47 ` [PATCH v4 1/7] smb/client: refresh allocation size after duplicate extents Huiwen He
2026-06-26 13:47 ` [PATCH v4 2/7] smb/client: handle smb2_set_sparse() failure in EOF-extending fallocate Huiwen He
2026-06-26 13:47 ` [PATCH v4 3/7] smb/client: handle smb2_set_sparse() failure in non-extending fallocate Huiwen He
2026-06-26 13:47 ` [PATCH v4 4/7] smb/client: handle overlapping allocated ranges in fallocate Huiwen He
2026-06-26 13:47 ` [PATCH v4 5/7] smb/client: reduce fallocate zero buffer allocation Huiwen He
2026-06-26 13:47 ` [PATCH v4 6/7] smb/client: emulate small mode 0 fallocate ranges at or past EOF Huiwen He
2026-06-27 18:04 ` Steve French
2026-06-26 13:47 ` [PATCH v4 7/7] smb/client: verify allocation after EOF-extending fallocate Huiwen He
2026-06-27 18:06 ` [PATCH v4 0/7] smb/client: fix fallocate and allocation accounting Steve French
2026-06-27 18:13 ` Steve French
2026-06-29 2:14 ` hehuiwen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=93d481fc-15d4-48c9-961a-3253200ece80@linux.dev \
--to=huiwen.he@linux.dev \
--cc=bharathsm@microsoft.com \
--cc=chenxiaosong@kylinos.cn \
--cc=dhowells@redhat.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=metze@samba.org \
--cc=pc@manguebit.org \
--cc=ronniesahlberg@gmail.com \
--cc=senozhatsky@chromium.org \
--cc=smfrench@gmail.com \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox