[mythtv-users] Managing storage groups intelligently

[Stephen Worthington]

On Tue, 1 Sep 2020 17:08:18 -0500, you wrote:

>> You can do what I do, which is to have my recordings go to the
>> partitions in my "Default" storage group, but also have another
>> storage group I call "Archives".  In my case, the "Default" drives CMR
>> drives and most of the "Archives" drives are shingled (SMR) drives,
>> which are unsuitable for recording to.  I currently have 7 drives on
>> "Default" so I am safe to do up to 14 recordings at once before I have
>> to worry about getting damaged recordings.  There are 5 drives on
>> "Archives".  When playing back recordings, MythTV will find the files
>> in any storage group, but will only record to the storage group
>> specified in the recording rule.  The default storage group used when
>> creating new recording rules is set in the "Default (Template)"
>> template rule.  So when my recording drives are getting full, I move
>> recordings from them to my "Archives" drives until I have enough free
>> space again.
>
>Thanks for the details. It appears like I could put SSD in Default group 
>and nothing else. I can create HD storage group and put all the other 
>spinning disks there. Since recording rules usually choose Default, it 
>will always go to SSD.
>
>In the night when the system is at rest, I will execute cache management 
>type copying from SSD?? to HD.?? I will keep the most recently accessed 
>files in SSD and others will go to HD. Like you suggest, I will copy xxx 
>as backup_xxx and delete xxx and rename backup_xxx as xxx.
>
>Do you think this will work based on your knowledge?
>
>Regards
>Ramesh

Yes.  That is analogous to what I am doing, but you will be doing it
daily and I only do it whenever my "Default" storage group is running
low on free space.

As you will be working the SSD hard, you will need to run TRIM
(fstrim) more often than the once a week that is standard.  In Ubuntu
this is now done from a systemd timer, but it used to be done from
/etc/cron.weekly.  I have changed it to daily, but you would need to
do some calculations to see how often you should be doing it.  Or you
could add the "discard" option to the SSD in fstab, so that TRIM will
be done every time space from a file is freed by the system.  The
problem here is that an SSD takes up to several seconds to erase one
of its storage blocks.  So you need to make sure it has already erased
blocks available, otherwise all write operations will be so slow as to
cause recordings to fail (and other problems for the system too).  The
way that SSD users are told to arrange this is to have 10% spare
blocks on the SSD that are not ever allocated to a partition, so that
even if the SSD is full, every time fstrim runs at least 10% of the
SSD's blocks will be then on the erased list and will be available for
writing.  But if that 10% gets used up and fstrim has not been run
again, then you will get the big erase times happening on every write.