[mythtv] Re: New idea for storing recordings to disks

[Joseph A. Caputo]

On Wednesday 29 June 2005 3:26, Hamish Moffatt wrote:
> On Tue, Jun 28, 2005 at 10:17:02PM -0500, Kevin Kuphal wrote:
> > Hamish Moffatt wrote:
> > >How would it know whether a particular location has sufficient disk
> > >space for a scheduled recording?
> > > 
> > >
> > How does it know now?   If Myth already has a mechanism to deal with 
> > full disk situations, it will work regardless of where the recording 
> > is  
> > destined, as long as it is checking the appropriate location for 
> > free  
> > space.   Again, this is one of there areas that could be enhanced by 
> > multiple locations in that if the default location for particular 
> > recording is full, Myth could be instructed to make various 
> > decisions on  
> > whether to expire content from the drive or simply record in a 
> > different  
> > location.
> 
> The point is that for MOST recording methods, Myth can't known in
> advance whether a recording will fit in a given location. Only PVR-x50
> recordings seem to have predictable file size - DVB, ATSC, RTJPEG etc 
> do not. 

But that's the case currently, anyway.  As it is now, we only have a 
setting that controls the minimum amount of free space that must be 
available before Myth will start a new recording.  There's no guarantee 
that there is actually enough space to *finish* the recording... you 
just have to set the number high enough and hope for the best.  With 
multiple storage locations, this wouldn't change, except that you 
wouldn't look at total free space, you'd look at free space available 
on any one mount point.

> Perhaps you can choose the one with the most empty space and hope 
> for the best though...

Exactly what it's doing now, pretty much.

Here's a pie-in-the-sky thought (and I realize this is probably *way* 
overkill, but it's an interesting idea nonetheless).  What if Myth had 
a sort of virtual filesystem?  That is, not a filesystem per se, but 
more of a content management layer, where a recording could be 'sliced' 
as it was being recorded, and each slice could potentially reside in a 
different location (retained in the database, of course).  Playback and 
other file operations would involve locating the various slices and 
'stitching' them back together, perhaps in a manner similar to 
BitTorrent (managing the parts, that is; not sharing over P2P).  Of 
course, all of this is analogous to the way a normal filesystem manages 
blocks on a device, and even the way LVM or RAID is able make a 
filesystem span devices.  The difference, of course, would be that no 
special filesystem tools would be required to manage the storage, and 
changing the storage configuration would be as simple as editing a text 
field in Myth setup, plus maybe moving some files and updating the 
database with their new locations.  The slice size could be 
configurable. of course.  Then the disk space issue becomes much more 
manageable, because you only have to check for enough space in a given 
location for the next slice (which would be a known, fixed size).

Just a thought; I'm not suggesting that we *should* have such a system; 
I'm not even sure if it's a good idea or not.  Just something to file 
in the 'idea closet' :-)

-JAC