On Wednesday 29 June 2005 12:35, Hamish Moffatt wrote: > On Wed, Jun 29, 2005 at 12:02:04PM -0400, Joseph A. Caputo wrote: > > On Wednesday 29 June 2005 11:31, Robert Tsai wrote: > > > Is your point that Myth should just not bother recording at all if > > > it > > > thinks it might run out of space? > > > > Actually, my *original* original point was simply that having > > multiple > > storage locations would *not* really make it much more difficult > > (just > > a little bit) for Myth to determine whether there is enough space to > > start a recording or where to record it. Perhaps I didn't do a good > > job of tying my original statements in to that conclusion... anyway, > > we've drifted a bit off-topic... > > But will the users understand that their recording died because one > particular storage location filled up, even though the others still > had > space available?
...which is kind of why I put forth the idea of 'slicing' the recordings as they're in-progress (see my post earlier in this thread). It allows you to take full advantage of *all* of the space across multiple mount points/devices, even though any one of them taken by itself may not have enough space. Without the ability to treat a collection of storage devices as a single entity (a la RAID or LVM), multiple storage locations would tend to be rather complicated to present to the average user. The difficulty with RAID and LVM (aside from initial setup) is in the various issues encountered when adding or removing a volume/device from the system (or when one fails). The 'slicing' approach circumvents these issues by letting the *application* manage its own content in a filesystem-independent way. Again, it's just an idea I had this morning... I'm not insisting that anyone start coding it -- actually, I'm quite satisfied with the current single-storage-dir approach, as I don't typically need more disk space than my current single TV recordings partition has. Maybe I need to be recording more stuff... -JAC _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
