The reason for the sucky perfomance is partly because they're using FUSE rather than an in-kernel solution, so it's going to be CPU heavy as well as incur lots of read latency, just like mhddfs and for the same reasons. Writes will be much slower, because of the read/modify/write required for parity updates.
Why would they choose this type of design if using an in-kernel solution would be much easier on the resources and thus faster?
Because it is very difficult to convince certain key kernel developers to include any kind of "union filesystem" (or look-alike, such as mhddfs) into the kernel proper.
They could still do it in-kernel (outside of Linus's tree), but that would require more maintenance than doing it externally with FUSE, and getting the code "right" is a heck of a lot trickier (and more dangerous) in-kernel than outside with FUSE.
So they've taken the sensible and easier route with it, and your data is safer as a result.
But performance will be more reliant on CPU horsepower using FUSE.
The in-kernel generic filesystem caching thing is fairly new (a year ago?), and has it's own quirks. But mainly I suspect they simply already had their own solution, and at this point they're just sticking with it for backward compatibility. Besides, what they do does work well enough for non-critical use.
But some of the performance loss you see could simply be due to not having correctly tuned Samba for MS-Win accesses. Didn't we have a thread on that here recently?
No idea, I must have missed that. Could somebody point me to it please? Thanks!
I forget where I read up on it, but I think it boils down to adding this line to the [global] section in /etc/samba/smb.conf:
socket options = TCP_NODELAY SO_RCVBUF=262140 SO_SNDBUF=262140 SO_KEEPALIVE
Previous Topic
Index
