On Wed, 8 Dec 2010 23:07:42 +1100 ronnie sahlberg <[email protected]> wrote:
> On Sat, Dec 4, 2010 at 10:40 AM, Jeremy Allison <[email protected]> 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 <[email protected]> _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
