by Obihoernchen » Wed Feb 06, 2013 5:38 am
Hi guys,
A complete guide is available at my blog:
obihoernchen.netfirst of all I want to hear your opinion about the following before I post a full guide in the guide section.
I got my PogoplugV2 some days ago and installed alarm. The default software is such a piece of ***** o.0
I have to use
NTFS because I have several 2,5" HDDs and I want to share content via USB with other friends too
So I installed everything set up samba and the performance sucks. Yes I expected that.
SambaRead ~16MB/s
Write ~5MB/s <-- sloooooow
Benched with dd, hdparm and values wereRead ~29MB/s <-- nearly USB 2.0 limit
Write ~6MB/s <-- ultra slow again...
Write speed is very important for me so I tried several things to speed this up.
First of all I had to improve the NTFS performance. And there is a really simple mount option which will increase write speed dramatically - big_writes
$this->bbcode_second_pass_quote('', 'T')his option prevents fuse from splitting write buffers into 4K chunks, enabling big write buffers to be transferred from the application in a single step (up to some system limit, generally 128K bytes).
1) Mount your HDD with noatime and big_writesI wrote a small guide how to do this with udevil (automount):
http://obihoernchen.net (6.)
Now I'm able to reach:
dd, hdparm benchRead ~29MB/s
Write ~28MB/s <-- great! So the NTFS bottleneck should be "fixed". I know other FS would produce less CPU usage but a lot of people want to or have to use NTFS...
Samba performance is better as well:Read ~16MB/s
Write ~11MB/s <-- more than 2x
That's pretty good already but there is even more potential.
Let's tune /etc/samba/smb.conf
There are several options which will increase speed slightly like:
$this->bbcode_second_pass_code('', 'socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE')
But 2 options will boost your speed really much:
write cache size$this->bbcode_second_pass_quote('', 'I')f this integer parameter is set to non-zero value, Samba will create an in-memory cache for each oplocked file (it does not do this for non-oplocked files). All writes that the client does not request to be flushed directly to disk will be stored in this cache if possible. The cache is flushed onto disk when a write comes in whose offset would not fit into the cache or when the file is closed by the client. Reads for the file are also served from this cache if the data is stored within it.
This cache allows Samba to batch client writes into a more efficient write size for RAID disks (i.e. writes may be tuned to be the RAID stripe size) and can improve performance on systems where the disk subsystem is a bottleneck but there is free memory for userspace programs.
The integer parameter specifies the size of this cache (per oplocked file) in bytes.
Default: write cache size = 0
$this->bbcode_second_pass_quote('', 'I')f this parameter is yes, and the sendfile() system call is supported by the underlying operating system, then some SMB read calls (mainly ReadAndX and ReadRaw) will use the more efficient sendfile system call for files that are exclusively oplocked. This may make more efficient use of the system CPU's and cause Samba to be faster. Samba automatically turns this off for clients that use protocol levels lower than NT LM 0.12 and when it detects a client is Windows 9x (using sendfile from Linux will cause these clients to fail).