[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