[mythtv] ringbuffer.cpp
Warpme
warpme at o2.pl
Sat Feb 15 20:06:02 UTC 2014
On 15/02/14 06:38, Jean-Yves Avenard wrote:
> Can you guys test the patch in this ticket?
>
> https://code.mythtv.org/trac/ticket/12045
>
> It has fixed all issues for me since I've applied it. Three frontends
> have been running liveTV for the past 5 hours, there's been no
> interruption; it hasn't happened in months before.
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org
>
I still believe there is reason to have fsync in separate thread.
Probably major one is that execution time of fsync isn't deterministic
and using it directly in realtime task (tfw) sooner or latter will make
problems. I can imagine huge dirty pages set flushed by flusher to
persistent storage. This can take tents of seconds and in this period
write operation will be blocked.
From 12045.patch & discussion I understand that moving to synchronous
write & fsync operations "fixes" problem. I think it rather masks
problem as I believe root cause is somewhere within OS mass storage
subsystem. I think it is worth to nail root cause. Maybe You can start
with as simple as possible storage setup (single local HDD with ext3, no
any LVM/mdadm/raid) and see how it works? If issue will be still present
- You can consider test with different distro. Archlinux is good
candidate as it is known with usage "vanilla" OS components (minimal or
zero patches) for kernel/libs/tools/programs. Arch users are reporting
perfect stability on their forums. I still believe given component
original devs are better in fixing problems than packagers (like i.e.
canonical).
br
More information about the mythtv-dev
mailing list