linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org,
	Bernhard Redl <bernhard@stinkt.kicks-ass.org>
Subject: Re: Very slow samba file transfer speed... any ideas ?
Date: Thu, 19 Jul 2012 13:04:03 +0200	[thread overview]
Message-ID: <201207191304.03829.Martin@lichtvoll.de> (raw)
In-Reply-To: <50076A4C.8080400@stinkt.kicks-ass.org>

Hi!

Am Donnerstag, 19. Juli 2012 schrieb Bernhard Redl:
> On 07/19/2012 03:42 AM, Shavi N wrote:
> > Hi,
> > 
> > I have btrfs volume, shared via samba. I have a directory of
> > documents that I want to backup on my server. win7 reports a
> > maximum of ~3.10MB/s transfer transferring the same directory on a
> > ext4 samba share I get 25MB/s +
> > 
> > Any ideas? Is it like that because of how btrfs works and is
> > setup?
> > 
> > Thanks, -- To unsubscribe from this list: send the line
> > "unsubscribe linux-btrfs" in the body of a message to
> > majordomo@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
> Did you try creating an huge file directly on your linux host
> with
> 
> dd if=/dev/zero of=/mnt/<YOURPATH>/file bs=1M count=1400
> 
> dd will report the speed afterwards.
> You can also try copying the documents from ext4 to a ramfs and then
> copy them from the ramfs to btrfs.

Depending on Samba/CIFS guarantees like "I have really written your file to 
disk" I tend to use at least conv=fsync with dd in order to get any 
realistic value of it.

Cause even an Intel SSD 320 isn´t that fast:

merkaba:~> LANG=C dd if=/dev/zero of=nullen bs=1M count=500 ; rm nullen
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.222668 s, 2.4 GB/s
merkaba:~> LANG=C dd if=/dev/zero of=nullen bs=1M count=500 ; rm nullen
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.255779 s, 2.0 GB/s
merkaba:~> LANG=C dd if=/dev/zero of=nullen bs=1M count=500 ; rm nullen
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.360679 s, 1.5 GB/s
merkaba:~> LANG=C dd if=/dev/zero of=nullen bs=1M count=500 ; rm nullen
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.289096 s, 1.8 GB/s

(due to the rm directly afterwards, the pagecache and the delayed 
allocation feature in modern filesystems most of that data did not hit the 
device at all. Nicely viewable in atop as WRDSK_CANCEL ;)

So dd often is not a disk but a memory benchmark. I just wanted to spread 
this knowledge once again, cause I see it again and again that people try 
to measure disk or filesystem speed with dd when they in reality measure 
mem speed.


And just to circumvent any with 1.4 GiB that would not have happened 
argument:

merkaba:~> LANG=C dd if=/dev/zero of=nullen bs=1M count=1400 ; rm nullen
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 1.34418 s, 1.1 GB/s
merkaba:~> LANG=C dd if=/dev/zero of=nullen bs=1M count=1400 ; rm nullen
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 1.27035 s, 1.2 GB/s
merkaba:~> LANG=C dd if=/dev/zero of=nullen bs=1M count=1400 ; rm nullen
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 1.43545 s, 1.0 GB/s


Nonetheless be gentle:

merkaba:~> fstrim -v /
/: 8204824576 bytes were trimmed



merkaba:~> free -m
             total       used       free     shared    buffers     cached
Mem:          7767       3849       3918          0        181        809
-/+ buffers/cache:       2859       4908
Swap:        12287          7      12280
merkaba:~> uname -a
Linux merkaba 3.5.0-rc7-tp520-toi-3.3-timekeeping+ #2 SMP PREEMPT Mon Jul 
16 19:08:43 CEST 2012 x86_64 GNU/Linux


As to my knowledge the Intel SSD 320 does not have internal compression, 
but BTRFS even was mounted with compress=lzo here. So zeros are bogus in 
that test case anyway – since I do not know any compressing harddisks they 
may just be a valid test case with a Samba fileserver.


With Ext4 without compression its slower:

merkaba:/home> LANG=C dd if=/dev/zero of=nullen bs=1M count=1400 ; rm 
nullen
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 4.25201 s, 345 MB/s
merkaba:/home> LANG=C dd if=/dev/zero of=nullen bs=1M count=1400 ; rm 
nullen
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 4.22669 s, 347 MB/s


But thats still more than the SATA-300 bus can yield:

merkaba:/home> LANG=C dd if=/dev/zero of=nullen bs=1M count=1400 
conv=fsync ; rm nullen
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 6.74884 s, 218 MB/s


Also note: dd is mixing up MiB and MB. Output used 1000 and input it 1024 
as base.

So enough of that now. fstrimming again.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

  reply	other threads:[~2012-07-19 11:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19  1:42 Very slow samba file transfer speed... any ideas ? Shavi N
2012-07-19  2:00 ` Bernhard Redl
2012-07-19 11:04   ` Martin Steigerwald [this message]
2012-07-19 12:39     ` Shavi N
2012-07-19 12:43       ` Fajar A. Nugraha
2012-07-19 14:19       ` Martin Steigerwald
2012-07-19 22:09         ` Shavi N
2012-07-20  9:15           ` Martin Steigerwald
2012-07-20  9:24             ` Remco Hosman
2012-07-20 10:23               ` Shavi N
2012-07-20 12:19                 ` Fajar A. Nugraha
2012-07-20 12:58               ` Martin Steigerwald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201207191304.03829.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=bernhard@stinkt.kicks-ass.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).