[mythtv] [mythtv-commits] Ticket #1835: Gradually delete big files to avoid I/O starvation on some filesystems

Chris Pinkham cpinkham at bc2va.org
Thu May 25 15:20:53 UTC 2006

* On Thu May 25, 2006 at 08:38:23AM -0400, Boleslaw Ciesielski wrote:
> My current plan is to try to see if the auto-expire can be delayed until 
> all pending deletes are finished. There is no reason to run auto-expire 
> before then as long as we are deleting faster than we are recording.

It's not just the auto-expire though, it is also the fact that they
will pop back up on the Watch Recordings screen unless deleted within 5
minutes.  If you add in the code to do open-unlink-removeDB-truncate, then
you could potentially fix this by moving the deletelock lock down to after
the unlink and before the truncate.  So then you are only truncating
one file at a time, but can unlink and delete the DB entries for multiple
files as quickly as possible.  Then it becomes an auto-expire only issue
since we're only concerned about free space at that point, and not
having to deal with files reappearing on the Watch Recordings screen.

> BTW, is the deletelock mutex only used to serialize the deletes for 
> performance reasons or is it also guarding some shared resources? 
> Perhaps the recordings can be deleted from the database (and unlinked) 
> before we grab the lock and start the truncate loop.

The deletelock mutex was added purely to sequentialize the unlinks.  The
only resource it is trying to sequentialize access to is the hard disk.
Previously if you went through real quick and deleted a few recordings
at the same time, we would fire off multiple threads all running the
unlink at nearly the same time which would really thrash the hard disk.
Adding a mutex was an easy way to spread out this impact.  So the
problem was worse at one point. :)


More information about the mythtv-dev mailing list