[mythtv-users] controlling disk space on "/" on mythtv backend

[Stephen Worthington]

On Thu, 11 Jan 2018 11:12:52 +0000, you wrote:

>On my backend my boot device and "/" directory is a 16GB Flash drive. I 
>did something stupid and filled up the drive.  So after deleting the 
>file I moved to the wrong place I'm back to the normal free space.
>
>But it brings up a question.  Does mythbackend use temporary disk space 
>somewhere on "/" that I need to redirect to one of my 2TB hard drives?  
>I have tons of free disk space just not on "/"
>
>My first guess is all the /var/lib/mythtv/* files to see which grow 
>large over time.  Obviously, Default and LiveTV are on the separate hard 
>drives.
>
>Jim A

Yes,you are living dangerously with a drive that small.  Depending on
how many recordings you have, the caches under:

/home<mythfrontend user>/.mythtv

can get very large - multiple gigabytes.  Those caches can be deleted
at any time and mythfrontend will re-create them as necessary.  But
you may want to move them to another drive and replace them with links
to the new locations.

If you have a cron job doing automatic database backups, you need
plenty of space to do that as it creates an ASCII .sql version of the
entire mythconverg database, and then compresses that using gzip.  I
believe it stores the .sql file in /tmp.

I have a modified version of mythconverg_backup.pl on my web server
that adds a new option (--tmpdir) that allows you to set the location
for the temporary .sqlfile.  You can get it from here:

http://www.jsw.gen.nz/mythtv/mythconverg_backup_jsw.pl

The database backups default to being stored here:

/var/lib/mythtv/db_backups

so you should change the location for that - I think you can set it in
the storage groups setup, and also on the mythconverg_backup.pl
command line in the cron job.

Anything that still gets stored under /var/lib/mythtv (eg artwork)
should be moved elsewhere, as the storage used grows with time and the
number of recordings.  I would suggest shutting down mythbackend, then
moving the /var/lib/mythtv directory to a drive with lots of space.
Then you can create /var/lib/mythtv as a link to the new location.
That ensures that any default usage of /var/lib/mythtv that you have
not set up to use a different location will not go to the SSD.  But be
aware that if the drive you use is also used for recordings, you may
be increasing the head movements on that drive, and hence decreasing
the number of recordings the drive can have happening on it at the
same time without losing some recording data.

And if you are running the optimise and repair database cron job
(optimize_mythdb), that requires space to make a temporary copy of
each database table as it does the optimising.  So you need room for a
temporary copy of the largest table in your database (normally
recordedseek) and its index file.  So see what this command shows you:

du -hc /var/lib/mysql/mythconverg/recordedseek.*

and you always need at least that much free space to avoid a database
crash during optimising.  Here is mine (I have over 20,000
recordings):

root at mypvr:~# du -hc /var/lib/mysql/mythconverg/recordedseek.*
4.0K    /var/lib/mysql/mythconverg/recordedseek.frm
5.6G    /var/lib/mysql/mythconverg/recordedseek.MYD
5.1G    /var/lib/mysql/mythconverg/recordedseek.MYI
11G     total

I have at some time had a problem with all of the above causing low
disk space on / - which I have now solved (at least for the moment) by
having / as a 100 Gibyte partition on my new NVMe SSD.  It is
currently using 45 Gibytes.

Whenever you manage to have / run out of space, you should always make
sure you run:

/usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl

to repair and optimise the database before running mythbackend again,
as the database may well have one or more tables crashed due to the
lack of space.  Fortunately MySQL and MariaDB are very forgiving about
what happens when the space runs out, so a simple repair normally
fixes everything.  Unfortunately, mythbackend can appear to be running
normally when tables are crashed, but it will in fact be unable to
write to the crashed tables.  There will normally be log messages
about SQL problems, but mythbackend will not otherwise notify you that
it has a problem.