[mythtv-users] Use of fsync

[John Pilkington]

On 22/10/13 17:32, Rich Freeman wrote:
> 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

For a long time I have used 'elevator=deadline' in my kernel boot line, 
and use 'ionice -c3' for most disk-intensive jobs, but I still see 
occasional things like this:

2013-10-22 16:07:33.081819 W 
TFW(/mnt/sam1/recb/1703_20131022125800.mpg:87): write(65424) cnt 4 total 
213568 -- took a long time, 1214 ms
2013-10-22 16:08:03.716604 W 
TFW(/mnt/sam1/recb/1703_20131022125800.mpg:87): write(64296) cnt 18 
total 1119540 -- took a long time, 6310 ms
2013-10-22 16:08:27.369549 W 
TFW(/mnt/sam1/recb/1703_20131022125800.mpg:87): write(65424) cnt 17 
total 1045656 -- took a long time, 5931 ms

and, from the (slightly non-standard) simultaneous mytharchive progress.log:

16:04:22  2013-10-22 Starting dvdauthor
16:04:22 ionice -c3 dvdauthor -x /home/John/arctmp/work/dvdauthor.xml
16:08:35  2013-10-22 Finished  dvdauthor
16:08:36  2013-10-22 Creating ISO image

That recording was the only one in progress at the time, and was from a 
dvb-t radio channel.  I don't think I've had faulty recordings, though.

The mytharchive work folder is on the DB spindle; the recording on another.

John P