From: Enzo Matsumiya <ematsumiya@suse.de>
To: Paulo Alcantara <pc@manguebit.org>
Cc: linux-cifs@vger.kernel.org, linkinjeon@kernel.org,
ronniesahlberg@gmail.com, sprasad@microsoft.com, tom@talpey.com,
bharathsm@microsoft.com, henrique.carvalho@suse.com
Subject: Re: [PATCH v3 2/2] smb: client: prevent premature discard of requests if reconnecting
Date: Wed, 7 Oct 2026 14:02:43 -0300 [thread overview]
Message-ID: <asZ12ZKIHpc5yPsn@suse.de> (raw)
In-Reply-To: <00e0fcdfdde0a281ed3f080040d6fb63@manguebit.org>
On 10/06, Paulo Alcantara wrote:
>Note that there's currently no backoff mechanism in either CIFS or
>netfslib for writeback, meaning that the write requests will be retried
>forever if the server goes offline. You'll end up with tasks hanging
>forever on close or fsync. Trying to fix that in the reconnect path
>doesn't seem the right way to do it, IMO.
Btw, I forgot perhaps the most important bit here -- whenever there's
a reconnect during a write, the file gets corrupted.
That's regardless of how long the downtime was. As soon as the first
task times out in cifs_wait_for_server_reconnect(), returning
-EHOSTDOWN, that request is lost, and data is corrupted.
Note that the writes (operations) _are_ resumed, but what was lost,
stays lost.
Again, I agree that retrying indefinitely might be wrong, but so is
corrupting data due to a short network outage.
I did try to relieve this situation with this patch, and TBH, after
reassessing it, I fail to see how/where this could be handled in netfs
or cifs I/O path.
The closest I got to a PoC was by loosening the restrictions to set
NETFS_SREQ_NEED_RETRY on smb2_writev_callback() and smb2_async_writev(),
and then we're obviously back to the retry-forever-but-no-corruption
dilemma.
Cheers,
Enzo
next prev parent reply other threads:[~2026-10-07 17:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 17:03 [PATCH v3 1/2] smb: client: fast fail sends if need to reconnect Enzo Matsumiya
2026-09-29 17:03 ` [PATCH v3 2/2] smb: client: prevent premature discard of requests if reconnecting Enzo Matsumiya
2026-10-06 19:48 ` Paulo Alcantara
2026-10-06 21:00 ` Enzo Matsumiya
2026-10-06 22:51 ` Paulo Alcantara
2026-10-07 15:04 ` Enzo Matsumiya
2026-10-07 23:25 ` Paulo Alcantara
2026-10-07 17:02 ` Enzo Matsumiya [this message]
2026-10-07 23:35 ` Paulo Alcantara
2026-10-06 18:14 ` [PATCH v3 1/2] smb: client: fast fail sends if need to reconnect Paulo Alcantara
2026-10-06 18:52 ` Enzo Matsumiya
2026-10-08 18:30 ` Enzo Matsumiya
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=asZ12ZKIHpc5yPsn@suse.de \
--to=ematsumiya@suse.de \
--cc=bharathsm@microsoft.com \
--cc=henrique.carvalho@suse.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=pc@manguebit.org \
--cc=ronniesahlberg@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.