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

[Mike Thomas]

On Fri, 17 Jan 2014 14:45:17 -0500
"Michael T. Dean" <mtdean at thirdcontact.com> wrote:
> 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.
                                                           ^ ext4
defaults. There, fixed that for you.

> >  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.

I /was/ beginning to wonder. I think it is worth reminding programmers
that turning off barriers can be a worthwhile debugging technique, but
others might do this without reading the caveats in the man page:

barrier=0 / barrier=1
       This enables/disables barriers.   barrier=0  disables it,  bar-
       rier=1 enables it.  Write barriers enforce proper on-disk order-
       ing of journal commits, making volatile disk write caches  safe
       to  use,  at some performance penalty.  The ext3 filesystem does
       not enable write barriers by default.  Be sure to enable barri-
       ers  unless  your  disks  are battery-backed one way or another.
       Otherwise you risk filesystem corruption in case of power  fail-
       ure.
>
> 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).

It seems we merely disagree on how much corruption is 'consumer-grade'.
I used to operate the database to my MythTV 0.22 system on an ext3
filesystem with hdd write caches on. Whenever the Radeon driver for the
second seat caused a crash (which was often) I usually saw corruption in
lots of tables. Repair table usually failed on a couple of tables each
time. Restoring from backups and re-entering things on the GUI quickly
became a bind. I soon moved to ext4, with its default of barriers on.
Oh, and I enabled binlogging too. To quote Baron Schwartz et al:

    The most common way to do point in time recovery with MySQL is to
    restore your last full backup and then replay the binary log from
    that time forward (sometimes called "roll-forward recovery"). As
    long as you have the binary log, you can recover to any point you
    wish. You can even recover a single database without too much
    trouble.

It /can/ be used for replication, but it is not the only reason.

Since doing that, my MythTV system improved markedly. Firstly, the
table corruption I observed after a crash was negligible and secondly,
I know now I can restore from backups to a point just before the crash
should I need to. I haven't needed to since. This speaks volumes to me.

Some time later I re-arranged the hardware to get rid of the second
Radeon card. This stopped the crashing. Now you can argue that I should
have removed the second Radeon card first but, as in all practical
situations, there were other matters which prevented me from doing so.

The point I make is MythTV 0.22 works with binlogging and barriers on
'consumer-grade' hardware without any trouble whereas MythTV 0.27
doesn't. Feel free to stick with barrier=0 and no binlogging if you
want, but the attached patch lets me have my cake and eat it too. It
should apply cleanly against 0.27.

Regards,

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugfix.patch
Type: application/octet-stream
Size: 7806 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140118/56d8a059/attachment.obj>