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

Boleslaw Ciesielski bolek-mythtv at curl.com
Thu May 25 15:56:25 UTC 2006

Chris Pinkham wrote:
> * 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.

Yes, that's what I meant. I will give it a shot. I hope this isn't over 
my head...


More information about the mythtv-dev mailing list