There is a bit of a performance hit with mhddfs --> everything gets relayed from the kernel to the mhddfs task (userspace) and then back to the kernel and on to the original task.
..
One project I might do if I get time/bored, is to write an in-kernel implementation of a simplified version of it, which would get rid of the double copying on reads/writes and make it all pretty much invisible performance-wise.
Back to this again. Last night, SWMBO & I were watching a BRRip of Fame(1980). Really good film, especially the cafeteria party scene. But playback stuttered annoyingly during that scene, which has a lot of fast movement, camera panning, and high bit-rate audio.
Today I poked at things, and noticed that the file plays more smoothly (though not perfectly) when not passing through
mhddfs. I think mythtv doesn't do enough read-ahead, an issue that is compounded by the frontend streaming content via the backend, rather than just reading the file itself.
So I patched the kernel on that box to intercept
open() calls to the videos hierarchy on the
mhddfs, redirecting access straight to the underlying files when the
open() is for an ordinary file
read. Doing this similarly reduces the stuttering we saw to almost non-existent levels.
Someday I've gotta figure out where Mythtv itself does the file reads, and insert an
fadvise() call there for proper read-ahead, or something.
Cheers
Previous Topic
Index
