On Fri, 2004-06-11 at 03:23, Douglas Furlong wrote: > > > Scot's probably right, that's the way it's going to be with Samba. But > > > if it's not getting the whole pipe, then maybe you can speed it up with > > > some kind of QOS/traffic shaping, maximizing the bandwidth that Samba > > > gets while leaving some minimum for other protocols/ports. > > > > Problem here is that I'm not in direct control of the link. I"m just a > > lonely end-user trying to get to my samba box at the other end of the > > world > > > > > If Samba is > > > slow even when it has the whole pipe to itself, then you could look at > > > some kind of replication setup, for example with rsync. But probably > > > either of my suggestions will cost you money/effort. > > If you have control of both boxes, may I suggest using NFS (tunnelling > it through an SSH/VPN connection for security), as I believe NFS offers > better performance of WAN's as compared to SMB. Yes I have control of the boxes. My File Server to my Laptop (Linux both) NFS is worst than SMB. > > There is the added benefit, that depending on mount time options, No options. > you > can instruct the system to not time out if the line goes down, in which > case your applications will "hang" but as soon as the link comes back > up, it will just carry on as if nothing ever happened, this will mean no > lost data, which is damn'd handy. Didn't really try that with NFS but on smb, it's re-establishes it itself. No prob > >From past experience if the connection to the SMB server drops, then you > have to restart the connection (if not the computer) and it all gets > VERY messy :( Hmm.. No such thing here. might me YMMV though > > You are also able to configure the size of the packets being sent back > and forth, so may be able to tweak for better performance. I would _if_ i knew how to do it