[mythtv] mutliple storage directories idea... ?

[Michael T. Dean]

Bruce Markey wrote:

> Michael T. Dean wrote:
> ...
>
>> Line 1222 of programinfo.cpp is the culprit, but unfortunately, I 
>> can't see an easy way to fix it.  We can't just trim the 
>> RecordFilePrefix off the left because it won't work with multiple 
>> hosts...
>
> You don't want to allow a server to access to any arbitrary full  path.

Yeah, but what's the likelihood that someone who puts an appropriate 
link under my recordings directory to damage my filesystem is going to 
be able to guess that my "mythtv" database user has a password "mythtv" 
so that they can put the bad basename in there.  ;)

>> I can't think of a non-invasive approach to use.  Ideas?
>
> Here's what I've written before that I'd like to see but I haven't
> needed this so far so I'd never gone past some simple proof of
> concept tests last winter.

This is definitely a much better solution.  I was going for the 
quick-and-easy "read-only" solution hoping it would be a building block 
toward a readable/writable solution, but going for the end goal is 
probably more appropriate--especially since  you have some code...

> -----------8<-----------8<-----------
>
> Even though I still don't need this myself, I did start on
> a prototype back in Dec. that allows a colon separated list
> for RecordFilePrefix. It correctly splits, reads from and
> writes to any of the dirs. Reading from the dirs throughout
> the code is pretty easy. For writing, I'd like it to make
> these choices:
>
> - prefer not full (above MinRecordDiskThreshold) over full
> - prefer local disk over remote mount
> - prefer a disk not in use by another recorder over one in use
> and if there is still more than one equal choice,
> - prefer the disk with the most free space
>
> The remaining problems are determining that a dir is on a local
> mount vs any type of remote mount (NFS, Samba, others?).

What about making the user specify?  For example, we could have two text 
boxes for recordings directory--one for "Local recordings directories" 
and one for "Remote recordings directories."  I think if we try to do 
the determination in code, we'll get into all sorts of portability 
issues.  And, when you think of really strange situations--like a union 
mount with a local filesystem on front and an NFS filesystem on back--it 
can even come down to "remoteness" of a filesystem being determined on a 
file-by-file basis.

> Also
> determining which backend is responsible for a directory if it
> is shared for reporting total free space properly

Not to mention whether multiple specified directories exist within the 
same filesystem.  Although with this approach--since it's not 
user-configurable through recording rules (i.e. put Simpsons in the 
Simpsons directory, etc.), it doesn't really make sense to put multiple 
directories that exist on the same filesystem into the list (but that 
doesn't mean it won't happen :).

> and which
> backend(s) may delete files. This isn't too bad if all NFS
> mounts are from disks that are local to another backend, The
> local backend would be responsible. However, if one of the
> dirs is a disk on a slave and that slave is down or if there
> is a shared NFS mount from a system that doesn't run a backend,
> exactly one backend has to take charge for that disk.
>
> If this all works, you can have more than one disk on a machine
> whose filesystems are not tied together so you can move files off
> one to take the disk out, replace it or do maintenance. A slave
> could have a local disk and paths to NFS mounts so if the local
> disk fills up it could fail over to writing across the network.
> A master could have paths to NFS mounts of the slaves' local
> disks so the master could play the slaves files even while the
> slave backend process is not running (but the machine would have
> to be up of course =). Etc.

Sounds good.  It would also be nice to add another priority for the 
user-specified directory (specified in a recording rule) after the 
prefer not full.  If there is no user-specified directory (i.e. it has 
the value "Default" or something), it will work exactly as you 
described.  Of course, adding the user-specified directory makes 
figuring out whether multiple dirs are on the same filesystem a problem 
that must be solved (as opposed to one to be taken care of through the 
lists, which would be possible if the rule says one directory per 
filesystem :).

Mike