[mythtv-users] SSD's for daily myth recordings storage and part time RAID for capacity.

Simon Hobson linux at thehobsons.co.uk
Fri Apr 22 16:22:43 UTC 2016


David Scammell <davescammell at gmail.com> wrote:

> I'm considering using a moderate sized ssd for daily myth recordings so that the larger RAID 5 array drives can be spun down for most of the day, perhaps only brought up during main telly watching hours or when anyone is about. I'm expecting the machine to record all the daily kid's programs with the main RAID array shut off to save on power and heat.
> 
> I'd like to copy (rsync/whatever) those recent recordings from SSD to RAID only when the RAID is spun up. I will be able to clear down sufficient free space on the SSD for the next days recordings so as to not need to expire anything straight way, at least at first but I'm struggling to work out how myth will be able to expire recordings from the RAID array once that gets full, as it will be available only part time.

This one has been stewing away at the back of my mind ...

One approach I can think of is simply to harness Myth's abilities directly. Set an appropriate value for how much space you want to leave on the raid array, and let Myth expire stuff as required. But I see a few wrinkles in the plan ...

1) If Myth isn't recording to the array (or more precisely, to a storage group located on the array) then it'll not autoexpire/delete to make space on it (AIUI). Workarounds I can think of are : does Myth have a call to trigger auto-expire/freeing of space; or setup a dummy recording onto the raid array to trigger it.

2) It's so long since I set it, I can't remember if the required space variable is global or per-filesystem, or something else. I think it's global so if you (for example) wanted to keep 20G free on the raid array, you'd also be forced to "waste" 20G of space on the SSD*.

3) There could potentially be situations where you record more in a day than you have free space for on the raid array (this kind of goes hand in hand with 1 & 2). So you might need to copy/move files one at a time, triggering auto-expire/deletion as you go.
I wonder if it's possible to set up a dummy recording which has very low bandwidth, start it before you start moving files, then move files one at a time, pausing if the free space becomes less than the size of the next file. Myth will remove something creating free space, and then the script can carry on. Finally, when the script has finished, stop the recording.

As long as the "free space to keep" value is larger than the largest recording file you might ever have, then this should work. IMO, the best way to avoid complications is to avoid duplicating what Myth does, and let it do it itself - that way you are not subject to database schema changes, and you don't need to worry about accidentally "corrupting" the database.

For bonus points, I suppose you could periodically check the free space on the SSD*, and it it's getting low then start another run to move files.


* Mind you, as long as the OS supports TRIM then keeping some spare space on the SSD will improve write performance. For a task like this, you are pretty well guaranteed to have all blocks on the volume holding non-zero data before too long - even when many of those blocks hold deleted files. AIUI, with TRIM support, the OS can signal to the drive that the blocks are deleted data, and the drive can add them to it's "free but not erased" list. In the background, the SSD erases blocks off this list and adds them to it's "empty blocks" list.
This important because erase cycles take time - so when there are erased blocks free, write performance is good. Once the empty block list is empty, performance drops quite significantly as the drive now has to pause while it erases blocks before it writes the data.
I do stand to be corrected on this !



More information about the mythtv-users mailing list