Very slow samba file transfer speed... any ideas ?

Very slow samba file transfer speed... any ideas ?

[Shavi N]

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,

Re: Very slow samba file transfer speed... any ideas ?

[Bernhard Redl]

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
> 

Re: Very slow samba file transfer speed... any ideas ?

[Martin Steigerwald]

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

Re: Very slow samba file transfer speed... any ideas ?

[Shavi N]

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

Re: Very slow samba file transfer speed... any ideas ?

[Fajar A. Nugraha]

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

Re: Very slow samba file transfer speed... any ideas ?

[Martin Steigerwald]

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

Re: Very slow samba file transfer speed... any ideas ?

[Shavi N]

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

Re: Very slow samba file transfer speed... any ideas ?

[Martin Steigerwald]

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

Re: Very slow samba file transfer speed... any ideas ?

[Remco Hosman]

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,

Re: Very slow samba file transfer speed... any ideas ?

[Shavi N]

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

Re: Very slow samba file transfer speed... any ideas ?

[Fajar A. Nugraha]

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

Re: Very slow samba file transfer speed... any ideas ?

[Martin Steigerwald]

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