[Linux-cluster] Re: Samba failover "impossible" due to missing cifs client reconnect?

[Axel Thimm]

On Wed, Sep 07, 2005 at 03:43:21PM -0500, Christopher R. Hertel wrote:
> On Wed, Sep 07, 2005 at 10:15:37PM +0200, Axel Thimm wrote:
> > After having setup our workarounds for NFS we are very happy with how
> > it's working. Now we're looking at Samba.
> > 
> > But we have quite a showstopper right at the beginning. The smb/cifs
> > clients, be it smbclient or Windows XP, don't like their TCP stream
> > being resetted and don't retry/reconnect (contrary to NFS).
> >
> > It looks like the protocol has no considerations for retries above the
> > TCP/IP level. So when the TCP stream is torn on the server's side due
> > to relocation (either due to crash/fencing or soft) any client
> > smb/cifs activity is broken at that time.
> >
> > This means that any data transfer via smb/cifs shares during the
> > relocation will fail, and there is nothing we can do on the server's
> > side. Or is there?
> 
> Windows clients will reconnect to the same server, and so will smbfs and 
> cifs-vfs.
> 
> I just tested this.  On a W/XP box I browsed through some directories on a 
> share served by Samba.  I then shut Samba down, and tried viewing some 
> different subdirectories of the same share.  Windows coughed up an error 
> dialog.  I then restarted Samba and Windows got happy again.  I could 
> browse through all of the subdirectories in the share.

Yes, that does work, but what I wanted to setup is a transparent
failover, so that network I/O recovers w/o any manual interaction.

I.e. I don't want to (soft) relocate the samba shares onto another
node due to load ballancing considerations and generate user visible
I/O errors and failures on a dozen clients.

> We've talked about Samba on GFS within the Samba Team, and various members
> have done some digging into the problem (Volker most recently, if I'm not
> mistaken).  Samba must maintain a certain amount of state information
> internally--including name mangling, locking, and sharing information
> that--is peculiar to Windows+DOS+OS2 semantics.  The problem is ensuring 
> that Samba's state information is also shared across the GFS nodes.
> 
> I've not had time to keep up with this development thread, but I know that 
> the folks working on Samba-4 are aware of the issues involved.
> 
> Chris -)-----
> 

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20050907/c3355f81/attachment.sig>