Re: Linux 2.6.29

Jeff Garzik
2009-04-04T23:03:37Z

Janne Grunau wrote:
> On Fri, Apr 03, 2009 at 07:30:37PM -0400, Jeff Garzik wrote:
>> David Rees wrote:
>>> The *only* reason MythTV fsyncs (or fdatasyncs) the data to disk all
>>> the time is to keep a large amount of dirty pages from building up and
>>> then causing horrible latencies when that data starts getting flushed
>>> to disk.
>> sync_file_range() will definitely help that situation.
>
> Jeff, could you please try following patch for 0.21 or update to the
> latest trunk revision. I don't have a way to reproduce the high
> latencies with fdatasync on ext3, data=ordered. Doing a parallel
> "dd if=/dev/zero of=file" on the same partition introduces even with
> sync_file_range latencies over 1 second.

Is dd + sync_file_range really a realistic comparison? dd is streaming
as fast as the disk can output data, whereas MythTV is streaming as fast
as video is being recorded. If you are maxing out your disk throughput,
there will be obvious impact no matter what.

I would think a more accurate comparison would be recording multiple
video streams in parallel, comparing fsync/fdatasync/sync_file_range?

IOW, what is an average MythTV setup -- what processes are actively
reading/writing storage? Where are you noticing latencies, and does
sync_file_range decrease those areas of high latency?

Jeff