[mythtv-users] 0.27: Stalls and other niggles - diagnosed

[Michael T. Dean]

On 01/17/2014 02:34 PM, Michael T. Dean wrote:
> On 01/17/2014 12:40 PM, Mike Thomas wrote:
>> because the problem stems from mythbackend instructing MySQL and
>> the filesystem to update the database files and wait for them to land
>> on the platters on each insert statement.
>
> MythTV doesn't tell MySQL to wait for the data to land on the 
> platters--/you/ do when you mount the file system with barriers 
> enabled.  You seem to have covered the options you have, so now you 
> just need to choose the one that's most appropriate for you, based on 
> both the value of the data to you (and whether it's worth the costs of 
> the various solutions) and the likelihood of an issue occurring due to 
> the solution you've implemented.  IOW, just how much is a bit of 
> recording data (possibly re-creatable, for example if it's just seek 
> data) worth to you in the event your system loses power in the middle 
> of a recording (which, will--and there's nothing you can do to make it 
> otherwise--result in at least a partial loss of some of that 
> recording, anyway).  In my mind, if the recording itself is screwed 
> up, who cares about the seek data I might lose?

Oh, and I should also say that I do /not/ recommend disabling barriers.  
I'm simply recommending that everyone look at the options, their costs, 
and choose the one most appropriate for their valuation of the data.

If you want enterprise-level reliability, and you're running on 
consumer-grade disk controllers (without battery backup), you should 
enable barriers (which is what barriers were designed to allow).  If 
this combination doesn't provide the performance you want/need, you may 
need to get enterprise-quality hardware (such as a battery-backed disk 
controller) or more-expensive, but faster, consumer hardware (like flash 
disks).

Mike