[mythtv] Storage Groups functionality
Michael T. Dean
mtdean at thirdcontact.com
Sun Feb 5 18:36:55 UTC 2006
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
More information about the mythtv-dev
mailing list