Re: [PATCH v3 2/2] smb: client: prevent premature discard of requests if reconnecting

[Paulo Alcantara <pc@manguebit.org>]

Enzo Matsumiya <ematsumiya@suse.de> writes:

> 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.

Yes, because we explicitly return a non-retryable error if the server
neve came back online.

Then we're back to whether using 'hard' mount option or 'retrans=' to
handle such cases.

> 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 agree.  Check the available mount options (hard and retrans=) to see
if they help with your case.

> 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.

Reconnects and retries are definitely not easy to handle.  This,
however, makes network filesystems quite interesting to work with,
though :-)

> 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.

Yes.  Let me know what you think and let's keep talking on how to solve
these issues.

Thanks for looking into them!