[mythtv-users] Use of fsync

[Gary Buhrmaster]

On Tue, Oct 22, 2013 at 3:18 PM, Rich Freeman
<r-mythtv at thefreemanclan.net> wrote:
> Does anybody know why MythTV uses fsync to force writes to disk when
> recording (in ThreadedFileWriter)?

Well, technically, I think MythTV ends up using fdatasync rather
than fsync on modern linux distributions, but for purposes of
discussion, that is not especially relevant.

> I just noticed that some of my recent recordings were getting
> truncated (a recent behavior change - though I can see why it might
> not be a bad strategy).  The use of fsync on a fairly busy drive
> basically kills drive throughput and as a result the buffers overflow.

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

For the "average" Linux system, suggesting to Linux to
flush the buffer(s) regularly results in an overall improved
experience.

On another end of the spectrum are individuals running small
memory, slow (USB or laptop drives?) that perform poorly at
every seek.  For those, every write is precious and every extra
seek is painful.  That is especially true if one is not using a
reasonably recent file system type (ext4, with extents, results
in far fewer seeks than ext3, for example, as long as the disk
is not too full).

Note that I expect that careful adjustment of the various
Linux tunables might produce reasonable results too, but no one
(TTBOMK) has build up a sufficient set of test systems to
be able to produce the statistics to support any particular
conclusion.

Gary