Can you try to copy with wired LAN? To rule out, that the problem is on the NAS and not with the wifi.
Greetings
David
I write faster to my NAS than i can read from it... 
but its just some MB/s difference.
How is the CPU load when writing/reading? (On your nas)
Pls change to your nas drive via command line e.g.
/media/UUID/
and test your read/write speeds with the two following commands
write:
dd if=/dev/zero of=tempfile bs=1MB count=10240
read:
dd if=tempfile of=/dev/zero bs=1MB count=10240
Afterwards you can delete the tempfile, but make sure you are on your shared harddisk/raid (/media/UUID).
Another thing you could try would be to use an FTP connection, but make sure you use a large file for speed test, because FTP gets slow if you use many small files!
Greetings
David
I would test FTP via cable too, just to rule out that it don't caps at 20MB/s again... That would show that the problem could just simply be the direction of your wifi transfer.
Greetings
David
It seems that you're not the only one who is having problems these days.: http://forums.openmediavault.o…wtopic.php?p=13328#p13328
Alltough i cannot reproduce the problem here...
Which Operation System are you using? I know Windows 7 has some Problem related to its own SMB version 2... Maybe its more related to Windows than OMV itself.
Greetings
David
Hi,
I had similar issues with file transfer over SMB with Windows 7.
Performance over SMB was really bad 20-30MB/s but with FTP everything worked fine (100MB/s).
I added "strict allocate = yes" to the global smb.conf restarted SMB. Now I have the same transfer speed for SMB as over FTP.
Google "strict allocate = yes" and check the Samba wiki for more information (couldn't add url, post was marked as spam).
I'm not a SMB guru but maybe someone could explain why this isn't already in the smb.conf or if it will impact something else to use this configuration?
It looks like it enables samba to use extents. Extents are something relatively new with filesystems compared to the age of samba. The "strict allocate" option was first in 3.5.7 but backported to older versions (OMV uses 3.5.6). The reason it isn't defaulted on OMV and still not the default on newer Linux distros is because it is actually slower on filesystems that don't use extents. If you are using ext4 or xfs, then it should help.
Good find! Guess I will try it on my systems 
Might have to add that to the wiki.
From my very quick tests, it looks like it benefits slower processors much more than fast processors. On one system, it went from 90 MB/s to 93. Another went from 110 to 110. I don't have a good Atom system to test this theory.
I'm running OMV on my ESXi server and the hardware dedicated to OMW should be more then enough.
Intel® Core i5-3470S
16GB RAM
HBA IBM M1015
2x 1Gbit nic
Asus RT-N65U router
Only cat 6 cables used
The network card and HBA card is configured with pass-through and 2GB ram given to OMV.
I'm using ext4 as file system and the hardware used should be more then enough to get full speed.
Before I changed the smb.conf I got 20-30MB/s when transferring files from one instance, but if I started two transfers they both got the same speed (total 40-60MB/s).
It was after that I tried FTP instead and noticed that the transfer speed was normal via FTP.
I read some forums regarding SMB and slow transfer speed to Windows and found the information on the SMB wiki which helped a lot.
Slower processors might benefit as well but I got a huge performance boost with this change.
Hi,
thanks a lot for sharing this. I´m writing a lot of recorded TV streams on my OMV (HP N40L). I will try this out this evening and report!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!