[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