[mythtv-users] Use of fsync

Eric Sharkey eric at lisaneric.org
Tue Oct 22 21:53:20 UTC 2013


On Tue, Oct 22, 2013 at 2:25 PM, Rich Freeman
<r-mythtv at thefreemanclan.net> wrote:
>The other problem is that many of the tuning
> parameters are system-wide.

Because in some respects it is a system-level problem.

There's a lot of system tuning that can be done with sysctl but much
of it is too coarse grained.

> If there are application-level settings like fadvise that we could be
> using, that at least would make sense.

I don't think there is.  Or, rather, the fadvise calls seem (to me) to
be the right ones, but the Linux kernel doesn't take full advantage of
them.  Why shouldn't an fadvise DONTNEED cause a page to be flushed to
disk sooner than it would otherwise?

At my day job, we have an application that writes a lot of data to
disk at fairly high rates.  Some files (big ones) are written
sequentially, while others are written randomly (smaller ones).  We
have no need of transactional integrity at short time scales.
Typically a job might run 24 hours, then we finally sync everything to
disk.  The random I/O was killing us even though these files were
small enough to fit in RAM.  We could find no way to get the kernel to
not flush pages from the small files to disk.  We tried bumping up
vm.dirty_expire_centisecs but this caused other problems.   We ended
just keeping this information explicitly in RAM and then writing these
files out sequentially as well, but it wasn't ideal.  It's kind of
frustrating, but you do what you can.

Ideally, MythTV should not be calling fdatasync, but given the
realities of the kernel, it's better than not doing it.

Eric


More information about the mythtv-users mailing list