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
Bernhard Redl
2012-Jul-19 02:00 UTC
Re: Very slow samba file transfer speed... any ideas ?
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. 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 >-- 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
Martin Steigerwald
2012-Jul-19 11:04 UTC
Re: Very slow samba file transfer speed... any ideas ?
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 -- 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
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 <Martin@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 >> > 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 > -- > 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-- 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
Fajar A. Nugraha
2012-Jul-19 12:43 UTC
Re: Very slow samba file transfer speed... any ideas ?
On Thu, Jul 19, 2012 at 7:39 PM, Shavi N <shavi64@gmail.com> wrote:> So btrfs gives a massive difference locally, but that still doesn''t > explain the slow transfer speeds. > Is there a way to test this?I''d try with real data, not /dev/zero. e.g: dd_rescue -b 1M -m 1.4G /dev/sda testfile.img ... or use whatever non-zero data source you have. dd_rescue will give a nice progress bar and speed indicator. Also, run "iostat -mx 3" while you''re running dd, and while accessing it from samba. In my experice, btrfs is simply slower than ext4. Period. There''s no way around it for now. -- Fajar -- 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
Martin Steigerwald
2012-Jul-19 14:19 UTC
Re: Very slow samba file transfer speed... any ideas ?
Am Donnerstag, 19. Juli 2012 schrieb Shavi N:> Hi,Hi Shavi,> 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/sDid you actually read and understand my mail? Do you really think that your local disks is/are yielding that transferrate? (Unless you are using BTRFS RAID 0/10 on lots of disks.) Thanks, -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Yes I read and understood your email. my btrfs volume consists of 11 HDD''s. I was very surprised with that result myself... On Fri, Jul 20, 2012 at 12:19 AM, Martin Steigerwald <Martin@lichtvoll.de> wrote:> Am Donnerstag, 19. Juli 2012 schrieb Shavi N: >> Hi, > > Hi Shavi, > >> 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 > > Did you actually read and understand my mail? > > Do you really think that your local disks is/are yielding that > transferrate? (Unless you are using BTRFS RAID 0/10 on lots of disks.) > > Thanks, > -- > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Martin Steigerwald
2012-Jul-20 09:15 UTC
Re: Very slow samba file transfer speed... any ideas ?
Am Freitag, 20. Juli 2012 schrieb Shavi N:> On Fri, Jul 20, 2012 at 12:19 AM, Martin Steigerwald > > <Martin@lichtvoll.de> wrote: > > Am Donnerstag, 19. Juli 2012 schrieb Shavi N: > >> Hi, > > > > Hi Shavi, > > > >> 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 > > > > Did you actually read and understand my mail? > > > > Do you really think that your local disks is/are yielding that > > transferrate? (Unless you are using BTRFS RAID 0/10 on lots of > > disks.)> Yes I read and understood your email. my btrfs volume consists of 11 > HDD''s. I was very surprised with that result myself...I think that you did not understood it. Why? Your dd tests where without conv=fsync – did you even try with conv=fsync to compare results? 11 really fast 15000rpm FC / SAS disks could possibly do 936 MB/s. But regular 7200rpm SATA disks depending to the on disk location might be as slow as 40-50 MB/s – just try fio disk-zone-profile on one if you do not believe this – and then even with 11 disks 936 MB/s is out of reach. And then speed depends on the BTRFS RAID level as well. And if BTRFS is using compression then testing with zeros is bogus anyway. Also its questionable whether CIFS will use 1 MiB blocksizes. It might be using it in most current kernels, since there have been some adaption – but I am not sure ATM whether they have been for reads or writes, they have not been for both, check wsize, rsize or similar named option maximums –, but thats also a point where to look. But then are the files that you transfer there that big at all? And what is the accesses pattern? Virtualbox VM images are usually not written sequentially to, so you need a random I/O workload. I do think in order to get more close to the possible reason of Samba slowness with BTRFS a simple dd test won´t help one bit. Even the conv=fsync case will most likely not be testing the workload that Samba exercises on the local disks. Some fio random I/O workload or dbench or filebench workload might be much closer. I think currently you are measuring something that has almost nothing to do with your real workload. 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Op 20-7-2012 11:15, Martin Steigerwald schreef:> Am Freitag, 20. Juli 2012 schrieb Shavi N: > >> On Fri, Jul 20, 2012 at 12:19 AM, Martin Steigerwald >> >> <Martin@lichtvoll.de> wrote: >>> Am Donnerstag, 19. Juli 2012 schrieb Shavi N: >>>> Hi, >>> Hi Shavi, >>> >>>> 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 >>> Did you actually read and understand my mail? >>> >>> Do you really think that your local disks is/are yielding that >>> transferrate? (Unless you are using BTRFS RAID 0/10 on lots of >>> disks.) >> Yes I read and understood your email. my btrfs volume consists of 11 >> HDD''s. I was very surprised with that result myself... > I think that you did not understood it. Why? Your dd tests where without > conv=fsync – did you even try with conv=fsync to compare results? > > 11 really fast 15000rpm FC / SAS disks could possibly do 936 MB/s. But > regular 7200rpm SATA disks depending to the on disk location might be as > slow as 40-50 MB/s – just try fio disk-zone-profile on one if you do not > believe this – and then even with 11 disks 936 MB/s is out of reach.My BTRFS array consists of 5 WD Green 2T disks. each of them goes a bit over 100MB/sec on sequential read/write. Remco> And then speed depends on the BTRFS RAID level as well. And if BTRFS is > using compression then testing with zeros is bogus anyway. > > Also its questionable whether CIFS will use 1 MiB blocksizes. It might be > using it in most current kernels, since there have been some adaption – > but I am not sure ATM whether they have been for reads or writes, they > have not been for both, check wsize, rsize or similar named option > maximums –, but thats also a point where to look. > > But then are the files that you transfer there that big at all? And what > is the accesses pattern? Virtualbox VM images are usually not written > sequentially to, so you need a random I/O workload. > > I do think in order to get more close to the possible reason of Samba > slowness with BTRFS a simple dd test won´t help one bit. Even the > conv=fsync case will most likely not be testing the workload that Samba > exercises on the local disks. > > Some fio random I/O workload or dbench or filebench workload might be much > closer. > > I think currently you are measuring something that has almost nothing to > do with your real workload. > > Ciao,-- 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
Martin, I agree with you 100% that dd does not measure proper performance (and that /dev/zero is not a very good test). Hence I''m asking.. I know that I get fast copy/write speeds on the btrfs volume from real life situations, but NOT with samba. So, is there something I can do to test why samba is slow transferring from win7 to a samba share on a btrfs volume? Thank you, On Fri, Jul 20, 2012 at 7:24 PM, Remco Hosman <remco@hosman.xs4all.nl> wrote:> > Op 20-7-2012 11:15, Martin Steigerwald schreef: > >> Am Freitag, 20. Juli 2012 schrieb Shavi N: >> >>> On Fri, Jul 20, 2012 at 12:19 AM, Martin Steigerwald >>> >>> <Martin@lichtvoll.de> wrote: >>>> >>>> Am Donnerstag, 19. Juli 2012 schrieb Shavi N: >>>>> >>>>> Hi, >>>> >>>> Hi Shavi, >>>> >>>>> 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 >>>> >>>> Did you actually read and understand my mail? >>>> >>>> Do you really think that your local disks is/are yielding that >>>> transferrate? (Unless you are using BTRFS RAID 0/10 on lots of >>>> disks.) >>> >>> Yes I read and understood your email. my btrfs volume consists of 11 >>> HDD''s. I was very surprised with that result myself... >> >> I think that you did not understood it. Why? Your dd tests where without >> conv=fsync – did you even try with conv=fsync to compare results? >> >> 11 really fast 15000rpm FC / SAS disks could possibly do 936 MB/s. But >> regular 7200rpm SATA disks depending to the on disk location might be as >> slow as 40-50 MB/s – just try fio disk-zone-profile on one if you do not >> believe this – and then even with 11 disks 936 MB/s is out of reach. > > > My BTRFS array consists of 5 WD Green 2T disks. each of them goes a bit over > 100MB/sec on sequential read/write. > > Remco > > >> And then speed depends on the BTRFS RAID level as well. And if BTRFS is >> using compression then testing with zeros is bogus anyway. >> >> Also its questionable whether CIFS will use 1 MiB blocksizes. It might be >> using it in most current kernels, since there have been some adaption – >> but I am not sure ATM whether they have been for reads or writes, they >> have not been for both, check wsize, rsize or similar named option >> maximums –, but thats also a point where to look. >> >> But then are the files that you transfer there that big at all? And what >> is the accesses pattern? Virtualbox VM images are usually not written >> sequentially to, so you need a random I/O workload. >> >> I do think in order to get more close to the possible reason of Samba >> slowness with BTRFS a simple dd test won´t help one bit. Even the >> conv=fsync case will most likely not be testing the workload that Samba >> exercises on the local disks. >> >> Some fio random I/O workload or dbench or filebench workload might be much >> closer. >> >> I think currently you are measuring something that has almost nothing to >> do with your real workload. >> >> Ciao, > > > -- > 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-- 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
Fajar A. Nugraha
2012-Jul-20 12:19 UTC
Re: Very slow samba file transfer speed... any ideas ?
On Fri, Jul 20, 2012 at 5:23 PM, Shavi N <shavi64@gmail.com> wrote:> Hence I''m asking.. I know that I get fast copy/write speeds on the > btrfs volume from real life situations,How did you know that? So far none of your posted test result have shown that btrfs vol in your system is FAST. -- Fajar -- 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
Martin Steigerwald
2012-Jul-20 12:58 UTC
Re: Very slow samba file transfer speed... any ideas ?
Am Freitag, 20. Juli 2012 schrieb Remco Hosman:> > 11 really fast 15000rpm FC / SAS disks could possibly do 936 MB/s. > > But regular 7200rpm SATA disks depending to the on disk location > > might be as slow as 40-50 MB/s – just try fio disk-zone-profile on > > one if you do not believe this – and then even with 11 disks 936 > > MB/s is out of reach. > > My BTRFS array consists of 5 WD Green 2T disks. each of them goes a > bit over 100MB/sec on sequential read/write.I tested 2 WD Green 1,5 TB and each of them goes about 90-100 MB/s at the beginning of the disk and about 40-50 MB/s at the end of the disk. So did you run fio disk-zone-profile on the whole disk and made a graph? If not, I do not believe your figures. Thanks, -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html