[mythtv-users] Recording storage suggestions

[Rich West]

Michael T. Dean wrote:
> On 05/23/2007 03:10 PM, Phill Wiggin wrote:
>   
>> I've been using Myth for a while now (since .14-.15ish) and have loved
>> it.  However, I've had harddrives die, LVMs become unrecoverable, and
>> run out of space more times than I care to count.
>>   
>>     
> ...
>   
>> I was in a situation similar to yours, and I bought a new drive and
>> upgraded to SVN.  My experience has been quite fruitful and I've had
>> very few issues.
>>
>> I'd say your best bets would be:
>>
>>  - Stay with .20 and replace your current 160G w/ a 500G (or 750G).
>>  - Upgrade to SVN and install your extra 160G for additional storage.
>>   
>>     
>
> I highly recommend against upgrading to SVN trunk just to get some new 
> feature.  Using SVN trunk means that you're signing up to keep up with 
> the development of MythTV--i.e. subscribe to and read /all/ the messages 
> from the -dev and -commits lists and work your own way through most 
> problems you encounter using the commit messages, source code, and the 
> 'net as your guide.
>
> If you were to start using SVN trunk now, you'd actually have to read 
> back through all the information that's come through -dev and -commits 
> since the release of 0.20 (unless you're willing to leach information 
> off people who have been following along).  It will be /much/ easier to 
> upgrade when everyone else is doing so when 0.21 is released.  At that 
> point, documentation--such as release notes and changelogs and tons of 
> info on the wiki--will be available to "catch you up."  If you upgrade 
> now, /you/ are responsible for doing all the research required to catch up.
>
> If your plan is a "one-time-upgrade-to-SVN-trunk" just to get some 
> features, leaching off others is not very considerate.  If, however, you 
> do plan to keep up with Myth development from now on and to contribute 
> code back into Myth, the leaching is more like "borrowing" (so make sure 
> you pay it back :), but in truth, working through the code yourself is 
> the best way to get the information/experience you need to start 
> contributing to Myth development.
>
>   
>> I've convinced a few friends to use Myth (they now love it), and
>> helped them decide on LVM.  Now that Storage Groups are available,  I
>> can't recommend LVM for Myth.  I lost a nearly full ~1TB LVM set
>> because one drive decided to give up the ghost.  My Myth recordings
>> aren't anything 'high priority', but it's annoying to try to re-record
>> everything. LVM adds points of failure to your whole recordings
>> storage area; Storage Groups insulate you against that.
>>   
>>     
>
> I completely agree with everything you said in this paragraph except for 
> the implication that you need to use either LVM /or/ Storage Groups.  I 
> used an HDTV-only system with 5 HDD's spread out over 2 backends for 4 
> months without LVM and without storage groups and never had any issues.  
> The key is symlinks and something like myth_archive_job.pl (which can 
> even be run automatically as a user job in Myth).
>
> Basically, set up your system so that the recordings directory is your 
> largest available partition (I like to use the largest hard drive I have 
> available with a single partition).  When it fills up, use 
> myth_archive_job.pl to move some recordings to other locations (on as 
> many disks/filesystems as you like), thereby freeing up most/all of the 
> space on the recordings directory.  Especially with SDTV, this is likely 
> to mean you may have to organize your recordings once every 3 or 4 
> months (depending, of course, on recording frequency and disk size) by 
> finding a time when you won't be doing to much recording and typing 
> "myth_archive_job.pl" into a terminal window (although you do need to do 
> a one-time edit of the directory locations in the script for your system).
>   

Thanks for all of the suggestions.  LVM, as has been pointed out, does 
add another layer, and concatenating volumes also adds another layer.  
All of which are potential points of failure.

As a stop-gap measure, I temporarily added my available 160GB drive to 
the existing 160GB drive via LVM.  I figure I will be picking up a 
 >320GB drive shortly, and migrating things over should be pretty easy.

My question about performance was mainly because I didn't know if a 
backend system  (3 tuners, possibly HDHR, and 3 frontends) would be able 
to take advantage of the better performing disks, or if it was 
over-kill/over-engineering...  However, I think it boils down to using 
what I've got at hand since it makes it easier to sell the idea of 
getting the HDHR + an antenna to my other half. :)

-Rich