[mythtv] Problems with using LVM for large storage

Kevin Kuphal kuphal at dls.net
Mon May 16 17:37:18 UTC 2005


Eric Thelin wrote:

>The better solution
>seems to be to make myth capable of handling multiple record directories.
>This would also allow us to simplify the installation by removing the 
>reliance on LVM for large scale installs.  We could either implement the
>same type of solution as my perl script or full handling of the multiple 
>paths.  If we add a field to the recorded table to store the destination 
>path and modify all routines that read or write the files directly to use
>that complete path.
>  
>
I have had this on my todo list for a while.  My target was going to be 
a "Storage Group" table that stored an index of groups with names and 
paths.  Then add a storage_group_id field to the recorded table.  This 
way, if additional per Storage Group features wanted to be added, they 
could be configured by adding fields to the Storage Group table (such as 
different auto-expiration thresholds, etc).

The code would then change to build the full pathname to the file using 
the storage group path.  Anywhere that assumed that a file exists in 
RecordedFilePrefix would have to be enhanced to look up the storage 
group and if no group was configured, use the default prefix.

I just haven't had time to code it yet.  I am also, like you, displeased 
with the idea of using LVM when storage groups would serve a similar 
purpose and also open the door to a variety of space management options 
that aren't possible with just a single storage point.

Kevin


More information about the mythtv-dev mailing list