I was trying to save wear on my SSD by putting the transcode temporary directory on a tmpfs drive and ran into some problems. Apparently there are some issues with the pruning process as the tmpfs disk kept eventually getting full. I setup a 4gb tmpfs file system and over the course of about an hour of watching 1080i live TV transcoded to 1080p the disk filled up with thousands of small 1-2mb files that ended in .ts. I saw in the log the pruning effort starting once the disk got to less than 100mb left, but either it quit or got stuck as the disk filled up a minute or two later. I tried this several times with the same result.
After looking at the files I decided to prune them myself. Here is the command that I used to prune the files:
find /your/transcodetempdirectory -name *.ts -cmin +2 -exec rm {} \;
What this does is search through the named directory and all sub-directories and deletes all files that end in .ts which have been modified more than 2 minutes ago. Now, it needs to be executed at regular intervals which can be done like this:
watch -c -n 30 "date; df -h -T /your/transcodetempdirectory;find /your/transcodetempdirectory -name *.ts -cmin +2 -exec rm {} \;;df -h -T /your/transcodetempdirectory"
This series of commands will cause the command to be executed every 30 seconds, along with adding some additional commands to show the disk space on the tmpfs file system (mounted at /your/transcodetempdirectory) before and after the deletion of files, plus a date command to show you when it last ran.
From my tests running a 1080i to 1080p transcode generates about 700mb of files over 3 minutes and when the delete command runs it gets down to about 400mb of files.
To automate this you need a way to invoke this at startup. To do that you must save this command as a script file (.sh extension), and mark it executable. The script only needs this one line (i.e. no bin/bash line necessary).
To invoke it you need a couple of “screen” commands in a script that runs at startup like this:
screen -dmS ramdiskclean
screen -S ramdiskclean -p 0 -X stuff "/etc/scripts/clearramdisk.sh\n"
The first command creates a virtual terminal session that runs detached (i.e. doesn’t need a logged in user to stay active), and the second command “pastes” the stuff in the quotes into the virtual terminal session called ramdiskclean and presses enter (the \n at the end). The watch command is in the script called /etc/scripts/clearramdisk.sh .
You can “attach” to this virtual session from your regular terminal session to see what’s going on by entering:
screen -r ramdiskclean
And to detach that virtual session and go back to your regular session enter into the virtual session:
ctrl-a d
Note that you don’t want to do ctrl-c or exit in the virtual session unless you want to terminate the watch command. Please read about the screen command in the linux documentation for more details.
Doing things this way has several advantages. First of course it gets around whatever the issue is with pruning. Second, you can have a decent size tmpfs filesystem for the transcoder temporary directory and not use more memory than you have to, as waiting for it to get to just 100mb short of full as the pruning does means you use up lots of memory for no good reason. Doing it this way, the only time you would use a lot of space is if lots of users are logged in transcoding at the same time.
Regarding the choice of more than 2 minutes, I just picked that out of the hat. From examining the files the last access time was never more than 2 seconds after the creation time, which leads me to believe that you could actually set that time down to 1 minute rather than two. Unfortunately there doesn’t appear to be an option on the find command to set the time by seconds, so the lowest you could go is 1 minute. Also if you want to key off of last accessed time rather than last modified time you can substitute “amin” for “cmin” in the find command.
I also tried playing a recorded TV show and the results were similar in that the transcode created a whole lot of small .ts files that it apparently only really needs for a second or two after creation if the last accessed time is to be believed. I haven’t tied playing a movie, so I don’t know if the way it creates these temporary files is any different.
The only real risk here would be that you delete .ts files that it still needed, which I think would just result in the stream using that file failing, as that’s what happened with the tempfs disk got full. If you you have enough memory you could make the tmpfs file even bigger and set “cmin” higher.
The bottom line here is that if you are going to use tmpfs for this directory, which is a really good idea if you are using a SSD given the high number of IOs being done to to it, a backstop appears necessary because the self pruning apparently has issues. Secondarily, if you use tmpfs you will save some memory by not keeping hundreds of megabyes or even gigabytes of .ts files in memory waiting for the pruning process that aren’t being used. In my test with a 4gb tmpfs file handling a single 1080i to 1080p transcode it looked like the oldest files were between half an hour and an hour old when the disk got full, before I set this up, and as it appears they are needed for only seconds after the last modify time, it sure doesn’t seem necessary to keep them around, even if the pruning issue didn’t exist.
