[mythtv] Storage Groups functionality

Chris Pinkham cpinkham at bc2va.org
Mon Feb 6 04:19:13 UTC 2006

> Regarding the Most Free Disk Space/Least Recordings, we should also 
> consider the effect multiple concurrent recordings will have.  Say 2 or 

Well, anything we could do to spread recordings out would be a benefit,
but even if we don't do anything to handle situations like this, there is
no negative effect since right now there is only one recordings directory.
I agree it would be nice if we could handle this, but doing this correctly
is going to involve coordination between all backends since a lot of
people (including myself) use shared NFS recording directories.

> 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 

If we wanted to handle this, we could perform a similar check to the one
that the status page in mythfrontend does.  We can look at the average
bitrate and use that combined with knowledge of what is currently recording
in order to determine where to put the next recording.  Again, this will
require coordination between all backends though since we may have shared
NFS storage between one or more backends.

> 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).

So far, I hadn't even considered the fact of multiple backends.  I was
assuming the Storage Groups would be global settings, but this may not
work with multiple backends.  If a user does not use NFS but instead has
multiple local recording directories on each backend, they would want
host-specific Storage Group values.  The load-balancing logic could be
coded to prefer local storage over NAS (yes, I mean Network Attached
Storage, just in case someone uses Samba, etc..)  I personally do not have
any Myth storage in my backends, I use a dedicated NFS server for my Myth
and other storage needs at home.  Myth has 3 dedicated filesystems on
the NFS server currently.

> 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.

I agree.


More information about the mythtv-dev mailing list