[mythtv] Alternative to LVM/Raid for multiple disks?

Jeff Wolf jeff at iwolfie.com
Wed Sep 8 00:25:44 EDT 2004


On Tue, 2004-09-07 at 21:51, Art Morales wrote:
> Hi All,
> 
> I just finished discussing this idea with a fellow Myther...  Right
> now, there are two ways to add more disk space in multiple drives to a
> mythbox: LVM and RAID.  I don't like the idea of LVM because the MBTF
> is now decreased overall, and if I loose a drive, I loose the whole
> volume.  Raid takes care of this, but now I'm either loosing ~30% of
> the diskspace (Raid 5) or gain no redundancy (Raid 1 (or is it 0?)). 
> Also, with Raid, I'm limited for the most part to equal size drives,
> which is not what people have usually lying around, and makes adding
> drives later kind of a pain.
> 
> Anyways, what if instead of having just one entry for video storage on
> the backend, we allow multiple ones (/var/video1 /var/video2 etc.)? 
> We could then add some very simple logic to the backend:  if less than
> X gb on current disk, store on next disk, and so on.  I would assume
> it would be a pretty simple addition to the code, but unfortunately, 
> this programming is beyong me...  I don't foresee any significant
> changes to the schema either...
> 
> The more I think about this idea, the more I like it because what if
> instead of using local drives, we use network shares mounted on
> diffent machines?  

why not set up a samba share or an nfs share on all of the machines and
then use a perl script to check available space and as long as no
recording is happening use symlink to point to available nfs/samba mount
point.  ie.  if you record to /home/video make that a symlink for the
nfs/samba partitions that are mounted and viola you have the space you
are needing, nothing on the backend need change.

> I have multiple desktops and servers in the house
> and they all have extra diskspace.  If I shared this space and made it
> available to the backend, I could suddenly have a 400gb store without
> buying anything new... (basically acting as a distributed file
> system).  On a simple gigabit network, there should be no issues with
> bandwidth, even with HDTV content.
> 
> Once you have such a system in place, one could use cron jobs to move
> certain files from one machine to the other and then transcode/process
> them there on a faster CPU (since the backend is more likely to have a
> slower CPU than the frontends).
> 
> Any takers?  I'm willing to help design the system a bit better if
> needed, but my programming skills are not up to par (unless you are
> talking Perl, then I can help :)
> 
> Art
> 
> ______________________________________________________________________
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
-- 

-Jeff
jeff at iwolfie.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20040907/f6be6469/attachment.pgp


More information about the mythtv-dev mailing list