[mythtv-users] remaining disk space / delete slowly

[Simon Hobson]

Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:

>> I think the bit about running out of memory (really it means the write cache has used all currently free memory) and corrupting things is bogus - the system will effectively pause at the that point with processes blocked in "wait for I/O" (wio) state until the disk subsystem catches up with the writes.
> 
> The problem is not bogus.  It is very real, and creates unwatchably
> damaged recordings.  The way it happens is that if the output to disk
> is blocked, while the input from the tuners continues (as it will),
> then the memory queue of data waiting to be written to the recording
> file will overflow.  The normal result is that data being written to
> the memory queue from the tuner gets lost - causing errors in the
> recording.

My fault for not being a bit more careful with terminology - I was referring to the suggestion that the filesystem could get corrupted if the system ran out of ram for the changes. Rather than corrupting the filesystem, the process will block until some of the data has been written out and freed up some space in the cache.

As you say, it WILL cause gaps in recordings when the system blocks waiting for I/O to complete - and the recording buffer overflows.

> As well as with deleting large files on ext3, I have seen this happen ...

Indeed, it's not too hard to cause such problems.

In a previous job we had a SCO Openserver system - fixed disk cache limited to 460,000k. One table in our dataset would reach 1G by the end of the year. The reporting tool had a habit of suddenly deciding to not use indexes with a seemingly insignificant change to a report - doing a full non-index join&select with this 1G table and several others. 
Result - disk cache flushed, disk request queue "well loaded", system at 99% or 100% wio, ... and the phones ringing with user for whom the system was effectively frozen. It could only be run at weekends and could take 40 hours !
At some point, I re-wrote the report in Informix taking care to use indexes well - and got it down to 90s runtime, while the system was in use, and without causing user complaints.