Hi Chris. Sweet I will give that a go (upgrading to dev version of SMB and using a later SMB client - Win7 or the like) Thanks a mill Jay On 23 June 2010 21:11, Christopher R. Hertel <crh@xxxxxxxxxxxx> wrote: > Jason, > > You're correct. Sorry. I'm a protocol geek, and I was addressing the > protocol issues. > > Samba 3 has SMB2 in the development tree, but not yet released as stable. > It should be pretty close to a testing release, however, so folks interested > in testing SMB2 support should watch the samba-technical list. > > If you are running any pre-Vista Windows products, then you are also correct > that SMB2 won't be supported on those. > > Having said all of that... The problem is that the Windows SMB1 clients > have no mechanism for recovering if the TCP connection is lost. If they are > using OpLocks, for instance, all cached updates are lost if the connection > goes down. The clients simply throw away state and start over. If the > applications running on those clients do not know how to re-establish the > correct state then they will lose data. > > This has nothing to do with CTDB, since it all happens on the client side. > > SMB2, however, has what are called "persistent file handles". The Windows > SMB2 client can maintain state even if the TCP connection fails. When the > connection is re-established, the client can resynchronize with the server > and all is well. > > Chris -)----- > > Jason Fitzpatrick wrote: >> Hi Chris.. >> >>>From reading up on the SMB2 protocol it seems that this is >> implemented within Vista and greater MS clients, but I do not seem to >> be able to track support for SMB2 within SAMBA >> >> I see that there is a Samba4AD project but cannot find rpms for RHEL >> and am a bit cagey about putting a dev version onto a critical file >> server. >> >> And the Citrix (client) servers are 2003 SMBv1 anyway so that kind of >> kills that anyway. >> >> Thanks >> >> Jay >> >> On 22 June 2010 17:08, Christopher R. Hertel <crh@xxxxxxxxxxxx> wrote: >>> Please note that the SMB/CIFS protocol itself does not gracefully recover >>> from a failover. SMB2 is much better in this regard. This is a client-side >>> problem due to limitations in the protocol and client expectations. >>> >>> Chris -)----- >>> >>> Frank de Groodt wrote: >>>> Make sure you use virtual public ip addresses managed by CTDB, not the ones bound to your NICS. >>>> >>>> Frank. >>>> ________________________________________ >>>> From: linux-cluster-bounces@xxxxxxxxxx [linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Abhijith Das [adas@xxxxxxxxxx] >>>> Sent: Tuesday, June 22, 2010 4:33 PM >>>> To: linux clustering >>>> Cc: Sumit Bose; Gunther Deschner; Simo Sorce >>>> Subject: Re: Samba Statefull Failover >>>> >>>> ----- "Jason Fitzpatrick" <jayfitzpatrick@xxxxxxxxx> wrote: >>>> >>>>> From: "Jason Fitzpatrick" <jayfitzpatrick@xxxxxxxxx> >>>>> To: linux-cluster@xxxxxxxxxx >>>>> Sent: Tuesday, June 22, 2010 6:43:36 AM GMT -06:00 US/Canada Central >>>>> Subject: Samba Statefull Failover >>>>> >>>>> Hi all >>>>> >>>>> Just wondering if it is possible to statefully migrate smb >>>>> connections >>>>> between cluster nodes, I am running ctdb (Samba's Cluster software) >>>>> but all connections are dropped when the service is failed between >>>>> nodes >>>>> >>>>> Setup is as follows >>>>> >>>>> 2 node cluster >>>>> DRBD backend shared storage in Master Master configuration >>>>> cman presenting GFS2 /Storage folder >>>>> Samba + Winbind + CTDB used to present /Storage/Test_Share via >>>>> \\clustername\test_share (both nodes are AD integrated) >>>>> >>>>> Connections to replicated storage are working fine, AD accounts are >>>>> authenticated correcly and smbstatus shows that CTDB is load >>>>> ballancing the cluster address between nodes correctly, >>>>> >>>>> When I run ctdb shutdown I expect existing connections to be migrated >>>> Also, I think "ctdb shutdown" is not the right command (Use "ctdb disable", it >>>> should all be in the man pages). Only one node should fail so that the >>>> other node can take over the IP address. If the IP address is not taken >>>> over, the clients will probably not be able to reconnect. >>>> >>>> Cheers! >>>> --Abhi >>>> >>>> -- >>>> Linux-cluster mailing list >>>> Linux-cluster@xxxxxxxxxx >>>> https://www.redhat.com/mailman/listinfo/linux-cluster >>>> >>>> -- >>>> Linux-cluster mailing list >>>> Linux-cluster@xxxxxxxxxx >>>> https://www.redhat.com/mailman/listinfo/linux-cluster >>> -- >>> "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X >>> Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel >>> jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. >>> ubiqx Team -- http://www.ubiqx.org/ -)----- crh@xxxxxxxxxxxx >>> OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@xxxxxxxxx >>> >>> -- >>> Linux-cluster mailing list >>> Linux-cluster@xxxxxxxxxx >>> https://www.redhat.com/mailman/listinfo/linux-cluster >>> >> >> >> > > -- > "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X > Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel > jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. > ubiqx Team -- http://www.ubiqx.org/ -)----- crh@xxxxxxxxxxxx > OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@xxxxxxxxx > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > -- "The only difference between saints and sinners is that every saint has a past while every sinner has a future. " — Oscar Wilde -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
