[mythtv-users] Use of fsync

Rich Freeman r-mythtv at thefreemanclan.net
Tue Oct 22 16:32:30 UTC 2013


On Tue, Oct 22, 2013 at 12:02 PM, Gary Buhrmaster
<gary.buhrmaster at gmail.com> wrote:
>
> And basically, the default, out of the box experience, of most
> modern Linux distros is just plain wrong in regards to disk I/O
> scheduling for applications such as MythTV.  With new systems
> coming with 8GB or more of memory, the eventual disk buffer
> flush can result in a long delay for other I/O, substantially
> impacting the perceived interactivity/useability of the MythTV
> system as a whole, no matter how fast the drive is (those with
> battery backed disk array caches that hide the delays are
> excepted).

I can see your point, although I think it depends to some extent on
the nature of the load.

Buffering is a solution for irregular loads.  If the load on the drive
is constant over long periods of time, then a buffer just delays the
inevitable, probably making things worse.  If the load on the drive is
irregular then a buffer reduces the impacts of bursts.  Several GB of
RAM could hold several minutes of HD video.  If your HD is busy for a
minute or two it would just build up, and once the drive cools off it
can catch up.  The sequential write performance of a hard drive is
very high - 60MB/s seems pretty typical for my filesystem and that is
with RAID1.

It seems like the fsyncs are more likely to cause problems, but when
problems occur they're likely to be more controlled in impact.

I wonder if setting a realtime I/O scheduling priority for actual
recordings is a better solution (which wouldn't include transcoding -
just actual recordings).

Rich


More information about the mythtv-users mailing list