[mythtv-users] Combined FE/BE using USB for all I/O?

[Simon Hobson]

Lindsay Mathieson <lindsay.mathieson at gmail.com> wrote:

> Say I'm looking at at:
> 
> - Main system+MythTV MySQL DB on a SSD
> - 4GB RAM
> - one 2TB Storage on USB3
> - No Transcoding 
> - No Comm Flagging
> 
> Worst case, simultaneous recording of 4 SD channels + 1 SD Playback

I would say it's likely to work most of the time - but you can only be sure by trying it !
BTW - you can help a lot by tuning MySQL. By default it uses a lot less memory than it can usefully use with a corresponding hit in disk accesses. The ideal is to tune it so all the main tables can be RAM resident. mysqltuner.pl is a useful tool for this.

Eric Sharkey <eric at lisaneric.org> wrote:

>> All it takes is one moment when the
>> disk is too busy and you will lose a block of data and seconds of one
>> or more recording.
> 
> I'm not a MythTV developer, but I can't think of any reason that
> should happen on a modern system, assuming MythTV itself is well
> written and the OS is properly configured.
> 
> This would only happen if the recording process writes to disk using
> synchronous, unbuffered writes, and is unable to complete these writes
> fast enough to issue a new read to the recording device before the
> recording device's buffer is full and recording essentially stops.


I'm not a dev - this is just picked up from previous discussions.

The OS default really doesn't work well - apparently. It lets large dirty buffers build up, then flushes them causing a period of high disk I/O which interferes with interactive performance (in particular, it causes momentary pauses in playback which rely on timely reading of data from disk).

MythTV uses an internal circular buffer per record stream. The record process drops it's data in the buffer, and a separate process copies any data in the buffer to the file and does an fsync to ensure it gets written to disk. The size of the buffer and write/fsync period are fixed at compile time (in-code constants). In the past I have thought that perhaps larger buffers and longer periods might help - but I never got round to trying it.
As it is, I don't think it takes long to fill the buffer - at which point the older part gets overwritten and data is lost.
The default time is 1 second, hence my comment earlier in the thread about the "tick from the disk" about once a second. It's not a fixed 1 second - the code does a 'write - fsync - "wait 1 second"' loop, so if the fsync is slow returning then the period will stretch. Given this, I suspect under heavy load all the loops would simply slow down to whatever seek rate the disk could manage - if the buffers were large enough not to cause any overflows.