[mythtv-users] Newbie

John Pilkington J.Pilk at tesco.net
Sat Dec 3 21:59:38 UTC 2011


On 03/12/11 18:02, Simon Hobson wrote:
> Gavin Whitehead wrote:
>
>> So are there whole threads dedicated to which are the best disks to use
>> [sound of can-of-worms opening] ?
>
> Oh dear, not another annelid inundation :-/
>
> Yes, there have been discussions, no I don't recall much of a
> consensus being reached. The only consensus I think we'll reach at
> the moment is that now is not a good time to be buying disk drives.
>
>
> Eric Sharkey wrote:
>
>> What are you doing that could possibly exceed the seek rate for a
>> mythTV recordings disk?  The mysql database is often seek bound, but
>> streaming  a half dozen or so recordings?  That doesn't make any sense
>> unless you're trying to run your backend with 16MB of RAM or have a
>> seriously fragmented filesystem.
>
> Amount of memory has little effect while recording - though it can
> help greatly with real-time concurrent commflagging or transcoding by
> allowing that process to use the recording data that's been cached in
> memory instead o fhaving to read it again (thus adding to the disk
> seek activity).
>
> Myth will sync the recording file every second. So for each recording
> that's active, there will be at least 2 seeks/second - seek, write
> data, seek, write filesystem data, and repeat ... I suspect on many
> filesystems there may well be 3 seeks as the OS writes the journal as
> well. That's a minimum, for some writes, there may be multiple
> operations updating the filesystem data (such as when a new extent
> needs to be added to the file.)
>
> It's done this way as, without this, the OS would cache large amounts
> of data in RAM, and then go to write it out in a big chunk. This can
> tie up the system to the extent that buffers start overrunning, and
> your recording gets corrupted.
>
>
> I have been considering fiddling with the parameters, but TBH I'm
> unlikely to find the time. I'm wondering if a larger buffer and less
> frequent syncs might improve overall performance.

Yeechang Lee had a version of the threaded filewriter that didn't use 
the 1-second sync; it was used in the 'bijou' builds on ATrpms and I 
used it successfully for some time before going on to 0.24.  The full 
Myth source code for that version is still available - as a single 60 MB 
package - at eg
 
http://dl.atrpms.net/src/f14-i386/atrpms/testing/mythtv-0.23.1-241_bijou20101002.src.rpm
but I'm sure there would be easier ways of getting at it.  It gave a 
quieter backend, but I don't think that was the reason he made it.

>
> And don't forget that doing other tasks (eg transcoding or
> commflagging) will also impact on performance.
>
> I haven't done any tests to find the limits on my current system, but
> on my previous system it could only cope with 2 recordings while
> watching another, and without commflagging. That was a Xen guest
> without a dedicated storage disk though.
>



More information about the mythtv-users mailing list