[mythtv-users] Software RAID and ionice

David Rees drees76 at gmail.com
Thu May 24 18:26:27 UTC 2007


On 5/24/07, Richard Freeman <r-mythtv at thefreemanclan.net> wrote:
> Well, without fully tracing the code this would tend to suggest that you
> are right:
>
> mythtv-0.20 # grep -r -C 5 fsync *
> libs/libmythtv/ThreadedFileWriter.cpp-    if (fd >= 0)
> libs/libmythtv/ThreadedFileWriter.cpp-    {
> libs/libmythtv/ThreadedFileWriter.cpp-#ifdef HAVE_FDATASYNC
> libs/libmythtv/ThreadedFileWriter.cpp-        fdatasync(fd);
> libs/libmythtv/ThreadedFileWriter.cpp-#else
> libs/libmythtv/ThreadedFileWriter.cpp:        fsync(fd);
> libs/libmythtv/ThreadedFileWriter.cpp-#endif
> libs/libmythtv/ThreadedFileWriter.cpp-    }
> libs/libmythtv/ThreadedFileWriter.cpp-}
>
> So, what happens if I just comment that out?  I don't have any kind of
> unusual partition sharing arrangements going on - in theory if
> mythbackend reads that file before it is written to disk the kernel
> should pull the read out of memory and still find the correct data.  The
> fsync should really only protect you from sudden power loss, and I'd
> rather run that risk than have frames dropping all the time...

In theory removing the fsync/fdatasync should allow the OS to group
writes and should improve performance. It would be interesting to know
if your system using using fdatasync, or fsync, since fsync also
flushes the file's metadata which means 2 writes go out instead of 1.

The biggest issue with those commands is that they are blocking
commands - which is why myth runs into the IOBOUND issues.

Of course, if your machine really is IOBOUND for some reason,
eventually the write will block as well.

You could just comment out the Sync call in the SyncLoop function, too.

-Dave


More information about the mythtv-users mailing list