[mythtv] ringbuffer.cpp

[Jean-Yves Avenard]

Le dimanche 16 février 2014, Warpme <warpme at o2.pl> a écrit :

> On 15/02/14 06:38, Jean-Yves Avenard wrote:
>
>>
>>  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.


I doubt that if a call to fsync starts to block, calling write
simultaneously is going to be rosy and dandy...

Despite, that's what the TFW class is for, even if the write is blocking,
it can still process getting data being fed and the buffer will typically
allows for several seconds worth of data


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



The thing is, it never used to cause me a problem until I got back from
holiday last month.

I don't recall changing anything before the problem started..

Maybe I should go back to an earlier kernel, 3.2 is the one I believe came
with the original Ubuntu 12.04

I'm certainly not reinstalling a new distro :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20140216/ca3f10a3/attachment.html>