Hi, Thanks.
This is the output: btrfs: $ dd if=/dev/zero of=/mnt/shared/misc/temp_file bs=1M count=1400 1400+0 records in 1400+0 records out 1468006400 bytes (1.5 GB) copied, 1.56841 s, 936 MB/s ext4: $ dd if=/dev/zero of=/mnt/500/VirutalBox_VMs/thor/thor-data/temp_file bs=1M count=1400 1400+0 records in 1400+0 records out 1468006400 bytes (1.5 GB) copied, 4.98993 s, 294 MB/s (just to show: $ mount /dev/sdi on /mnt/shared type btrfs (rw,relatime,space_cache) /dev/sdc1 on /mnt/500 type ext4 (rw,relatime,data=ordered) ) $ uname -a Linux Wolverine 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47 CEST 2012 x86_64 GNU/Linux So btrfs gives a massive difference locally, but that still doesn't explain the slow transfer speeds. Is there a way to test this? Also I forgot to say, this is on a 1gbit LAN On Thu, Jul 19, 2012 at 9:04 PM, Martin Steigerwald <mar...@lichtvoll.de> wrote: > 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 >> > majord...@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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
