[mythtv] [mythtv-commits] Ticket #2242: Recordings not being deleted fast enough

[Michael T. Dean]

On 08/26/06 22:16, Boleslaw Ciesielski wrote:

>Michael T. Dean wrote:
>  
>
>>I had just come up with a patch and was testing/verifying it when 
>>Boleslaw posted another one to your ticket ( 
>>http://cvs.mythtv.org/trac/ticket/2242 ).  His leaves a couple of 
>>issues unhandled, so I recommend testing mine (attached).
>>    
>>
>Hmm, what do you think is left unhandled?
>  
>

Here's the comment I'll submit with the patch when Trac allows.

Mike


I was working on this at the same time as Boleslaw and had come up with 
a similar patch, but with a couple of changes.  First, using size_t for 
fsize is unsafe as it will overflow (the overflow happened to create a 
value that was "close enough" to the right value on some 
systems--including the ones on which it was tested), so we need to use 
off_t.  Also, the file size we compute is only an estimate (that can be 
off by a lot), so if we decrement the estimate for the initial 
truncation, it could end up being a much larger truncation than desired.

In my patch, I truncate the file first to the estimated filesize (the 
file is almost definitely not written in the minimum number of blocks 
possible, so the estimate is low).  For example, on a 5.5GiB recording 
of mine, the estimated filesize is 5.5MiB smaller than the size on 
disk.  Therefore, if we don't truncate to the estimate first, the 
initial truncate would be ~9.5MiB instead of the 4MiB/500ms target.  
There are obviously several other ways of achieving the goal of 
truncating to the estimated file size first, but the approach I used 
seemed least intrusive to the existing code.

Note that we cannot use st_blocks*512 to determine the size on disk, 
either, as the units of st_blocks is actually undefined.  Some 
implementations use units of 512bytes ( 
http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/stat.h.html 
).  Therefore, an estimate (like Boleslaw's or mine--same idea, just 
different math, but the same result) is probably best.