[mythtv-users] remaining disk space / delete slowly

[James Linder]

> On 12 Jul 2016, at 8:00 PM, mythtv-users-request at mythtv.org wrote:
> 
>> Just for clarification, the reason for having delete slowly selected 
>> is so recordings are recorded over with a new recording (once) instead 
>> of with zeros now and a new recording later (twice).
> 
> No, the slow deletes are simply to allow MythTV to spread the I/O 
> requirements for deleting a file (generally a very large, multi-gigabyte 
> file) over a long period of time (IIRC, about 2min/GB) rather than 
> telling the OS to delete the entire, huge file and letting it force all 
> that I/O to occur "immediately". Therefore, if your system has other I/O 
> requirements (such as, for example, writing out recording files for new 
> recordings that are currently in progress, or writing information to 
> your MySQL database (eg, about in-progress recordings), or reading 
> information from your MySQL database (eg, to refresh the information 
> about your existing/remaining recordings), that (much, much) 
> higher-priority I/O can occur without having to wait on the unimportant, 
> low-priority I/O associated with deleting a recording.  This can be very 
> important when deleting a bunch of huge files because it's possible for 
> the new recording information to grow too large for the system to keep 
> in memory before it's written to disk at which point information  is 
> lost (and files are corrupted--including recording files and even 
> potentially your MySQL database data files).

Can someone who KNOWS offer some explanation, this sounds like gibberish

A file is an inode plus house heeping to say where in the hierarchical tree (AKA the file system) it appears
A file consists of 
1 sector of pointers to data sectors
1 sector of pointers to a sector of pointers to data sectors
1 sector of pointers to a sector of pointers to a sector of pointers to data sectors

during delete nothing happens to the sea of data sectors
Where does this huge I/O come from

If you choose (say) ext4 file system then file extents replace the traditional block mapping and journal overhead apply, and the devil in the detail (which may explain long delete times)

James