<div id='cm_signature'></div><div class="cm_quote" style=" color: 
#787878">On Wed, Jul 13, 2016 at 8:07 PM, stinga <<a 
href="mailto:stinga+mythtv@wolf-rock.com">stinga+mythtv@wolf-rock.com</a>> 
wrote:</div><br><div id="oldcontent" style="background: rgb(255, 255, 
255);"><blockquote style=""><p dir="ltr">On 13/07/16 02:37, James Linder 
wrote:
<br>
> Can someone who KNOWS offer some explanation, this sounds like 
gibberish
<br>
>
<br>
> A file is an inode plus house heeping to say where in the hierarchical 
tree (AKA the file system) it appears
<br>
> A file consists of
<br>
> 1 sector of pointers to data sectors
<br>
> 1 sector of pointers to a sector of pointers to data sectors
<br>
> 1 sector of pointers to a sector of pointers to a sector of pointers 
to data sectors
<br>
>
<br>
> during delete nothing happens to the sea of data sectors
<br>
> Where does this huge I/O come from
<br>
>
<br>
> 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)
<br>

<br>
It is an ext3 thing. It was slow on large files due to the way the data 
<br>
is stored. Google will explain it for you.
<br>
If using ext3 then tick 'slow delete' otherwise leave it unticked.
<br>

<br>
Not sure what happens internally if you do a slow delete on a non-ext3 
<br>
mount, hopefully it is ignored.
<br><br>
</p><p dir="ltr"></p></blockquote><div id="ID_1468398622002"> I don't 
think it hurts. JFS on my recording drives and slow deletes enabled. No 
glitches.</div><blockquote class="" style=""><p></p>
</blockquote></div>