Thanks Shonky! That's good info and worth looking into. I'll have a look if I can find more real-life speed numbers on the net, preferably on systems with a regular desktop CPU. (which is what I'll be using since I have one laying around here anyway)
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? Any specific reason? The same goes for the Linux build-in cache solution you mentioned earlier. Why would they not use this? Because the option wasn't there in the beginning and it's too much hassle now to implement it so they just keep on supporting their own solution to the problem?
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!
Previous Topic
Index
