Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Samba gives me 24 MB/s read and 44 MB/s write, while ftp gives 97 and 112 MB/s under the same circumstances.

The documentation says that

Generally, you should find that Samba performs similarly to ftp at raw transfer speed.

In my case it clearly doesn't.

Where can I find tips on how to debug Samba performance?

Or alternatively tips for replacing Samba with something else? (I can't use ftp, unfortunately, as I need something that can be used with rsync/rsnapshot.)

More details:

  • Both computers are running Ubuntu 10.10 (using Samba because I have a Mac as well)
  • The Samba share is on a local home network, mounted as

    $ mount
    //server.local/share/ on /mnt/share type cifs (rw,mand)
  • Samba performance was tested by copying (cp) a single file of ~4GB to and from the share, using time for timing and calculating transfer speed by hand.

  • ftp performance are the numbers from the ftp client for get/put of the same file.
  • iperf gives network speed ~900 Mbits/s
  • bonnie++ gives disk speeds >200 MB/s on both sides for block reads as well as block writes
  • Tried changing the parameters suggested in the performance tuning HOWTO (read/write raw, read size, socket options), most of them made little to no difference. (The one that made a difference caused write speed to drop 50%.)
share|improve this question
Update: According to the Samba mailing list anno 2009 the performance issues stem from smbfs/cifs rather than the Samba server. – j-g-faustus Jan 21 '11 at 13:47
up vote 3 down vote accepted

Actually FTP has quite an efficient data throughput rate once it gets going. The overhead that slows things down is with the getting a file downloading in the first place. That's not to say that there isn't a problem with Samba here. It should be performing nearly identically.

To be honest, I don't have much of a clue where you should start trying to fix this.

Ideally you'd be able to drop another computer in there with a reference install of Samba (eg Windows) and test that as both a client and server against the Ubuntu machines. Then you'd know which machine was the problem, if it was just one direction that was the problem and then you'd be able to report bugs based on this and/or find a workaround for the interim.

A while back I saw something about certain network hardware glitching under Samba. It was both switches and network adapters but I can't for the life of me find anything about it. It was probably such an edge case that it's not worth considering.

How about we sidestep Samba? FTP might not work but what about NFS? It probably has the highest transfer speeds out of the lot (in my experience) and it should handle rsync fine.

You could also look at FUSE-mounting the FTP server so rsync can bully it.

share|improve this answer
Thanks for tip and feedback - I had no idea that it's possible to cifs-mount FTP? I'll look into NFS as well. If the poor Samba performance is something non-trivial and not Ubuntu-related, perhaps it belongs on the Samba mailing list or some such rather than here? – j-g-faustus Jan 14 '11 at 21:02
Yours is probably the best answer I'm going to get :) Thanks again. – j-g-faustus Jan 15 '11 at 16:10
you can mount ftp resource: curlftpfs [user@]host:[dir] mountpoint [options] – jet Jan 24 '11 at 16:30

What kind of performance do you get from running rsync over ssh? Maybe you could do your rsync with ssh and then also use samba for when you need to transfer stuff between your mac?

share|improve this answer
rsync over ssh gives 60 MB/s, about midway between Samba and FTP. But just saw a tip elsewhere that rsync in daemon mode (having one machine be rsync server) can on par with FTP, I'll try that next. – j-g-faustus Jan 21 '11 at 8:05

you can try this in smb.conf

socket options = SO_KEEPALIVE SO_REUSEADDR \

oplocks = yes

write raw = yes
read raw = yes
share|improve this answer
I've tried some of them. TCP_NODELAY: Tiny improvement. write raw and read raw: No discernable difference. SO_SNDBUF and SO_RCVBUF: Reduced write performance with 50%, didn't pursue further. I'll check out the rest when I get the chance. – j-g-faustus Jan 21 '11 at 13:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.