[mythtv-users] automating storage moves

MythTV mythtv at ncc1701.serveftp.net
Thu Feb 11 01:04:04 UTC 2010


Slightly OT I think..

> 
> 
> It looks like you got your solution, but you asked me to share, so
> here's code I'm using.
> 
> mc.sql and mclog.sql create the DB tables addtoq.sh is the userjob
> script to insert into the queue Makefile is the ... er... make file :)
> mythq.c is the program that does the moving
> 
> Yes, the code is not very well documented, and far from the best code
> I've written... but it has served my well for nearly a year :)
> 
> aaron

Part of the solution might be 'read only' directories in a storage
group..

For example, add /a /b and /c to the list of directories for the storage
group
but make 'c' not writable by the myth backend. (implicitly un-writable
means
the backend will attempt to write and fail. "explicitly un-writable"
would require
a database change to allow storage directories to be marked read-only).

An external process (with correct group membership for example) could
migrate recordings
from /a or /b to /c, and they would remain playable without storage
group changes.

Expiration will remain a problem, though I use this for recordings which
are not meant
to expire.

A full blown solution would include multiple storage groups, and an
explicit hierarch
which allows recordings to 'migrate' rather than 'expire' when space is
needed.
This would allow each backend to have a local recording pool (which
could be accessed
via NFS) which would auto-migrate "aged" recordings to a central storage
pool (NAS maybe)
over time without user intervention. (This could be a hour, or a month
later...)

Migration is assumed to be slow, so the "min free" threshold would have
to be set carefully.
Migration throughput must be managed to avoid buffering and network
contention issues

Dave



More information about the mythtv-users mailing list