[mythtv] Storage Groups functionality

[Michael T. Dean]

On 02/05/2006 01:16 PM, Chris Pinkham wrote:
> As far as implementation goes, I think it would be a lot easier to
> just handle the Storage Group at the record table level and not at
> the recorded table level.  I think we should go one step farther
> than we are now with the 'basename' column and add a 'dirname' (or
> whatever it is called) column.  This would hold the directory of
> the file (obviously).  This way we don't have to deal with storage
> group changes, etc. like when a user decides to change the directory
> on one of their storage groups.  I think the ability to move
> recordings from one Storage Group to another is a nice-to-have, but
> not a requirement for the initial implementation.  The
> directory-determining logic could look at the record.storagegroup field
> and if it was a normal group name, it would use the directory specified
> for that group, but if it was one of the special virtual groups such
> as 'Most Free Disk Space' or possibly 'Least Recordings' or others,
> then it would perform a few calculations to figure out which directory
> out of all the real Storage Groups should be used.  Perhaps the default
> would even be to just use the storage group with the most amount of
> disk space free, or there could be a special 'Default' storage group
> where the group name was not user-editable, only the directory.
>   

Good ideas.

Regarding the Most Free Disk Space/Least Recordings, we should also 
consider the effect multiple concurrent recordings will have.  Say 2 or 
3 recordings start simultaneously, the same directory will have the most 
free space/least recordings at the start, but may not after the 
recordings finish.  This may result in recordings being auto-expired 
from this directory (if near the end of available storage) when choosing 
different directories may have allowed all three to finish successfully 
without auto-expiring other recordings.  Also, choosing the same 
filesystem for simultaneous starts may cause an I/O bottleneck.

The round robin is nice for spreading I/O across multiple spindles, but 
may actually cause problems with multiple network filesystems (i.e. if 3 
NFS mounts are chosen for 3 concurrent HDTV recordings while the system 
is doing near-real-time commflagging or... instead of choosing some 
local and some remote filesystems).

In the initial implementation, at least, we could ignore these issues as 
long as we give the user the ability to explicitly choose a storage 
group at the record table level, as you mentioned.

Mike