[mythtv-commits] Ticket #12411: threadedfilewriter - 'Maximum buffer size exceeded' & 'Taking to long to flush..'

MythTV noreply at mythtv.org
Sat Mar 14 06:05:56 UTC 2015


#12411: threadedfilewriter - 'Maximum buffer size exceeded' & 'Taking to long to
flush..'
----------------------------------------+---------------------------
 Reporter:  thekingofspain@…            |          Owner:  jyavenard
     Type:  Bug Report - Hang/Deadlock  |         Status:  closed
 Priority:  minor                       |      Milestone:  unknown
Component:  MythTV - Recording          |        Version:  0.27.4
 Severity:  medium                      |     Resolution:  Invalid
 Keywords:                              |  Ticket locked:  0
----------------------------------------+---------------------------

Comment (by Gary Buhrmaster <gary.buhrmaster@…>):

 Replying to [comment:3 thekingofspain@…]:
 > From the threads mentioned, there is a patch that seems to corrects this
 issue.

 One part of the patch disables fsync/fdatasync functionality.  That may
 fix one symptom for some, while at the same time reintroduce the other
 symptoms that adding fsync/fdatasync solved for others, as the author of
 the patch warned.  You can go back in the history to understand why the
 fsync was added, and why it is (on average) goodness.  Unless you can show
 facts why all of that information is now completely wrong, you are
 unlikely to sway anyone into thinking that reverting to the old problems
 is a good way forward.

 Certain file system types seem to be more problematic than others.  If you
 are willing to accept higher risks, disabling barriers on XFS might work
 for you.  Or not.

 It is possible that a first approach (that might be acceptable to the
 devs) would be a clean patch that allowed someone to configure their
 particular system via an appropriate mythtv-setup setting page to choose
 whether to disable fsync for those with special needs as long as the
 default stayed the same.  I suspect the hardest part is likely the mythtv-
 setup (and upcoming web) configuration piece, with all the warnings about
 how you may be breaking functionality, and do you really, really want to
 make this change.  Perhaps the more complete approach would require a
 complete rethinking and re-factoring of all the code to accommodate all
 systems and file-systems in some sort of dynamic fashion, trying,
 desperately, to handle systems that are fundamentally under-resourced.

 Of course, no one is preventing you from building your own programs with
 the patches you find useful to yourself, and accepting any of the fallout
 that goes with it.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/12411#comment:4>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list