[mythtv-users] Deleting Recordings

[Stephen Worthington]

On Wed, 5 Oct 2016 08:00:48 -0700, you wrote:

>The reason I bring it up is that my system will be recording five shows 
>at once while I am watching something else previously recorded when the 
>previous nights 'delete' kicks in.  I would not want that delete to 
>affect the five recordings or the playback.  Just wanting to know if 
>MythTV was clever enough to just schedule the delete to after the 
>simultaneous recordings, when the system is more idle.
>
>Jay

How many hard drives are you using to record 5 shows at once?  That
feels like too many for just one hard drive (unless it is an SSD).  I
have had go data missing from recordings when there were too many
happening at once.  Also, do you run mythcommflag?  If so, is your CPU
fast enough to do the flagging in real time (so that it gets its data
from the RAM buffers instead of from disk)?  If it is an older CPU,
then each mythcommflag could be using as much disk I/O as a recording
or playback would, although probably a bit less as the older CPU can
not process the data as fast as a recording can receive and store
data.

I have a rule of thumb that I do not want to have more than two
recordings happening per hard disk.  That is probably quite
conservative, but it allows for playing back at the same time, and for
when another recording starts overlapping the old one.  During the
overlap periods (usually around the hour or half hour), twice as many
recordings can be running due to the overlap.  So that can push my
system up to 4 recordings per hard drive for 5 minutes or so (my
usually allowance for pre- and post-roll).  My CPU is a quad core
capable of doing at least 4 commflag jobs in real time, so I have it
set to do that (max 4 commflag jobs, jobs start when the recording
starts).  But when there are more than 4 recordings happening, I can
get mythcommflag doing I/O to flag a recording that started at a time
there were already 4 recordings being flagged, so I want to leave
enough overhead to allow for that.

The thing to remember about hard disks is that when there is more than
just one file on the disk being accessed, the heads have to move back
and forth between all the different files, and also occasionally to
filesystem data areas to update the file size and so on.  Modern hard
disks have incredibly fast read and write speeds once the heads are at
the right place, but moving the heads has not speeded up much for
years, so if the files are at opposite ends of the disk, then the
heads moving back and forth can take a very long time.

The extra activity from a delete operation varies from one filesystem
to another.  It used to be that only XFS and JFS were recommended to
be used for recordings as they were the only available filesystems
that did deletes in a low impact way.  Then the option for "slow
delete" was added.  I believe the way that works is to truncate the
file a number of times, deleting a certain amount of storage off the
end off the file each time, until the file is small enough to be
deleted safely.  That was necessary if you where using EXT2 or EXT3 or
some other types of filesystem for recordings, as their delete
operations on large files caused bursts of very high activity by the
system that could not be broken into in time for a recording to not
run out of buffer space.  I have never tried it myself, but apparently
EXT4 has fixed this and is OK for recordings.  I use JFS for all my
recording partitions.  On filesystems with low impact delete
operations, the impact is very small indeed and you do not need to
worry about it.  So if you have been having problems with deletes
happening at the same time as recordings, then I would recommend
converting your recording partitions to JFS or XFS to fix that.