[Samba] Copying between physical drives within samba mount - veryslow.

[panos]

Thanks for the response.  Yeah I saw the same behavior with NFS.  It
would be nice to have an rpc.move.  

However, if I use netatalk the does not copy across the wire.  I have
not looked into the detail of the protocol.  However, it has its own
limitations.


Do you know of any movement in this area?  Logging in directly is not an
option for our clients.  I have looked at netatalk, samba, nfs and
webdav stuff.

Panos


-----Original Message-----
From: Mitch (WebCob) [mailto:mitch at webcob.com] 
Sent: Saturday, December 11, 2004 3:56 PM
To: panos at kamaradata.com; samba at lists.samba.org
Subject: RE: [Samba] Copying between physical drives within samba mount
- veryslow.



> -----Original Message-----
> From: samba-bounces+mitch=webcob.com at lists.samba.org [mailto:samba-
> bounces+mitch=webcob.com at lists.samba.org] On Behalf Of Panos
Koutsoyannis
> Sent: December 11, 2004 1:11 PM
> To: samba at lists.samba.org
> Subject: [Samba] Copying between physical drives within samba mount -
> veryslow.
> 
> I have a situation with a linux box that has several drives mounted
under
> /master
> say /master/drive1 and /master/drive2 ..etc.
> I mount /master on my windows machine or os x machine using samba.
> 
> when I move files from /master/drive1 to /master/drive2 the copy
process
> is very slow.
> 
> it seems samba actually sends the file over he network from the linux
> machine to the pc on which it is mounted and back to the linux
machine.
> 
> This only happens when there are different drives involved.  however
if i
> move files within the same drive it is fast as expected.
> 
[Mitch says:] This is similar to Linux itself - if you were moving
within an
NFS mount point, you would move... which I believe is commonly
implemented
as a hardlink to the second location OR a copy if on a different
physical
location, then an unlink from the old location...

Windows / SMB has the same limitation in the protocol - There is no "rpc
move" used (or even existing I think?) so it does what it has to do
within
the protocol - you will of course see much faster throughput by doing
these
major moves locally on the server box through a shell if that is an
option
for you.

m/