Re: Very slow samba file transfer speed... any ideas ?
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 re...@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 mar...@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 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
Re: Very slow samba file transfer speed... any ideas ?
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 sharedbuffers cached Mem: 7767 3849 3918 0181809 -/+ 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
Re: Very slow samba file transfer speed... any ideas ?
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 mar...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Very slow samba file transfer speed... any ideas ?
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
kernel BUG at fs/btrfs/extent_io.c:1893!
Hi, I have this problem after trying to run btrfsck. I have new 11 HDDs WD 2tb, on two RAID controllers Arch Linux, latest kernel. What I was doing was copying and reading multiple data at the same time After getting I/O errors while trying to access through samba and while trying to run a VM with files stored on volume, I ran a btrfsck but it failed. [ 7155.485832] [ cut here ] [ 7155.486210] kernel BUG at fs/btrfs/extent_io.c:1893! [ 7155.486575] invalid opcode: [#1] PREEMPT SMP [ 7155.486965] CPU 2 [ 7155.486975] Modules linked in: nfnetlink_log nfnetlink hwmon_vid reiserfs btrfs zlib_deflate libcrc32c microcode ghash_clmulni_intel cryptd cx22702 cx88_dvb videobuf_dvb cx88_vp3054_i2c dvb_core rc_winfast tuner_simple tuner_types eeepc_wmi asus_wmi pci_hotplug tuner cx88_alsa snd_pcm snd_page_alloc snd_timer snd i915 drm_kms_helper cx8802 cx8800 cx88xx tveeprom btcx_risc videobuf_dma_sg mei(C) i2c_i801 drm intel_agp soundcore i2c_algo_bit videobuf_core v4l2_common e1000e videodev media rc_core i2c_core iTCO_wdt iTCO_vendor_support button acpi_cpufreq mperf processor pcspkr fan video thermal sparse_keymap rfkill coretemp intel_gtt wmi evdev vboxnetflt(O) crc32c_intel vboxdrv(O) ext4 crc16 jbd2 mbcache usbhid hid sd_mod mptsas scsi_transport_sas mptscsih mptbase ahci libahci libata xhci_hcd ehci_hcd scsi_mod usbcore usb_common [ 7155.490485] [ 7155.491187] Pid: 2549, comm: btrfs-delayed-m Tainted: G C O 3.4.4-2-ARCH #1 System manufacturer System Product Name/P8Z68-V LX [ 7155.491976] RIP: 0010:[a05f3a0f] [a05f3a0f] repair_io_failure+0x17f/0x1c0 [btrfs] [ 7155.492849] RSP: 0018:8803e5a4b740 EFLAGS: 00010246 [ 7155.493679] RAX: 8803e5a4b770 RBX: 023f77d8 RCX: 023f77d8 [ 7155.494536] RDX: 1000 RSI: 023f77d8 RDI: 8803fa4a0108 [ 7155.495410] RBP: 8803e5a4b7b0 R08: ea000f21d400 R09: [ 7155.496301] R10: R11: 0001 R12: 1000 [ 7155.497206] R13: ea000f21d400 R14: 8803fa4a0108 R15: [ 7155.498128] FS: () GS:88041f30() knlGS: [ 7155.499096] CS: 0010 DS: ES: CR0: 8005003b [ 7155.500062] CR2: 7f3ea3ee7000 CR3: 0180b000 CR4: 000427e0 [ 7155.501059] DR0: DR1: DR2: [ 7155.502073] DR3: DR6: 0ff0 DR7: 0400 [ 7155.503103] Process btrfs-delayed-m (pid: 2549, threadinfo 8803e5a4a000, task 880406bb7710) [ 7155.504168] Stack: [ 7155.505234] 8803e5a4b740 023f77d8 [ 7155.506354] 8803e5a4b770 8803e5a4b770 [ 7155.507493] 88030001 023f77d8 8803fa4a0108 [ 7155.508663] Call Trace: [ 7155.509822] [a05f43b2] repair_eb_io_failure+0x82/0xb0 [btrfs] [ 7155.511018] [a05ca362] btree_read_extent_buffer_pages.constprop.111+0x112/0x120 [btrfs] [ 7155.512249] [a05cab2a] read_tree_block+0x3a/0x50 [btrfs] [ 7155.513491] [a05b05d3] read_block_for_search.isra.32+0x203/0x3d0 [btrfs] [ 7155.514761] [a05afceb] ? generic_bin_search.constprop.34+0x6b/0x180 [btrfs] [ 7155.516046] [a05ac5a9] ? unlock_up+0x159/0x180 [btrfs] [ 7155.517344] [a05b29fc] btrfs_search_slot+0x3ec/0x900 [btrfs] [ 7155.518662] [a05b7ef3] lookup_inline_extent_backref+0xa3/0x470 [btrfs] [ 7155.520001] [a05b8d83] insert_inline_extent_backref+0x63/0x100 [btrfs] [ 7155.521342] [81159acf] ? kmem_cache_alloc+0x13f/0x150 [ 7155.522703] [a05b9f29] ? __btrfs_free_extent+0x229/0x7b0 [btrfs] [ 7155.524083] [a05b8ec1] __btrfs_inc_extent_ref+0xa1/0x1f0 [btrfs] [ 7155.525481] [a05becc8] run_clustered_refs+0x5f8/0xa00 [btrfs] [ 7155.526891] [a05afceb] ? generic_bin_search.constprop.34+0x6b/0x180 [btrfs] [ 7155.528330] [a05b5b25] ? __find_space_info+0x85/0xa0 [btrfs] [ 7155.529781] [a05bf245] btrfs_run_delayed_refs+0x175/0x450 [btrfs] [ 7155.531254] [a05b5e1c] ? block_rsv_release_bytes+0xec/0x1b0 [btrfs] [ 7155.532718] [814675ae] ? __mutex_lock_slowpath+0x24e/0x340 [ 7155.534153] [a05d0e9f] __btrfs_end_transaction+0x9f/0x350 [btrfs] [ 7155.535560] [a05d1168] btrfs_end_transaction_dmeta+0x18/0x20 [btrfs] [ 7155.536986] [a061f49a] btrfs_async_run_delayed_node_done+0x16a/0x1b0 [btrfs] [ 7155.538437] [a060167d] worker_loop+0x13d/0x570 [btrfs] [ 7155.539892] [a0601540] ? btrfs_queue_worker+0x320/0x320 [btrfs] [ 7155.541358] [810731d3] kthread+0x93/0xa0 [ 7155.542831] [8146bbe4] kernel_thread_helper+0x4/0x10 [ 7155.544314] [81073140] ? kthread_freezable_should_stop+0x70/0x70 [ 7155.545819] [8146bbe0] ? gs_change+0x13/0x13 [ 7155.547301] Code: 68 f4 ba e0 b8 fb ff ff
