[cifs-protocol] [Pfif] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior

[Jeff Layton]

On Wed, 8 Dec 2010 23:07:42 +1100
ronnie sahlberg <ronniesahlberg at gmail.com> wrote:

> On Sat, Dec 4, 2010 at 10:40 AM, Jeremy Allison <jra at samba.org> wrote:
> > On Fri, Dec 03, 2010 at 06:22:01PM -0500, Jeff Layton wrote:
> >>
> >> Treating different calls differently for timeouts sounds like the road
> >> to special-case madness. It seems to me that the best behavior would be
> >> to have the client wait for a reply indefinitely if the server is
> >> responding to periodic echoes. If that's unacceptable then perhaps a
> >> tunable timeout that defaults to something very long (10 minutes or so).
> >
> > +1 from me. "hard" mounts shouldn't drop connections whilst the
> > server is responding to SMBecho requests.
> 
> 
> In NFS,   hard mounts also mean that the connection will transparently
> be re-established on connection failures.
> That is difficult in cifs since of its statefullness.
> (While nfs is partially stateful, sane people stay well clear of the
> stateful parts (nlm))
> 

Well, NFSv4 is stateful, but it was designed with the idea that state
might need to be reclaimed. CIFS/SMB/SMB2 really weren't. Ok, that's not
completely true with SMB2, but file locking is still broken, IMO.
There's nothing that prevents another client from racing in and
stealing your locks when the connection goes down. Maybe durable
handles help this case...I'm not sure.

Linux CIFS does reclaim state to some degree today. Filehandles are
reclaimed on reconnect. Lock reclaimation code is still stubs however.
In any case, reclaiming state in CIFS is always going to be racy...

I did a bigger writeup of this problem and possible solutions, and
cross posted to a set of the usual lists. The subject is:

    cifs client timeouts and hard/soft mounts

So far, the discussion has mainly been around timeouts, but consistent
handling of disconnections is also a part of this.

Hard and soft are necessarily going to have a different meaning with
CIFS than with NFS. My suggestion is that we use those to direct what
happens after a socket disconnection occurs.

"hard" should mean that state is reclaimed ASAP and calls are retried.
"soft" should mean that errors are returned to callers after a
disconnect.

I'm still struggling what "soft" should mean for stateful objects like
files and locks however. Should we still try to reclaim them, or should
we declare them invalid and just return -EBADF on every syscall that
takes one of those fd's?

There's also the open question of whether new syscalls on a soft mount
should return an error when the socket is disconnected, or should they
wait for the socket to be reestablished?

-- 
Jeff Layton <jlayton at samba.org>