On Sun, Jul 24, 2011 at 2:39 PM, Tom Metro <[email protected]> wrote: > While researching to buy/build an HTPC (likely to run XBMC) I ran across: >....
> > This is a good illustration of why we'd be better off getting > unRAID-like functionality added to a solid, widely used OS, like Linux > or FreeBSD. Though if you dig through the FAQ it does say unRAID is > "based on Slackware Linux" w/kernel 2.6. It also says that the individual data drives are formatted with ReiserFS. A quick google search implies that the source code to their changes are available, but its not clear how. Their forums have discussions about possible GPL violations, where some claim the source is included with any server product and others claims this is insufficient/incomplete. It may be that the core technologies are available already as source and could be pulled into a mainstream distribution. However, it's not clear that there is actually that much going on here. If you look at http://lime-technology.com/technology/usershares unRAID along with the other links you gave, their technology becomes a lot less mysterious. At the block level, they have a single parity drive which is bigger then any data drive. Failure of more then one drive, means some data is lost. They avoid complete filesystem failure in this case, by formatting each data disk with a separate ReiserFS filesystem which runs independently of the other data disks. These individual filesystems are user visible and if you access your data this way, you explicitly know for each directory/file which disk the data is on. They then layer their "usershare" filesystem view on top of this so the data drive divisions are not visible, but they are still there. The drives are numbered and for any particular directory path, the drives are searched sequentially starting at their root directories until a match is found. A later drive with the same path would be hidden by an earlier drive. So if you have a /drive2/Foobar directory with lots of stuff and then make a directory /drive1/Foobar, you will now see an empty directory under the "usershare" view. It also means that in the "usershare" view a directory subtree can be full even if other disks are not. It should work well with MythTVs storage directory system where the software already does arbitrary placement of data files based on space availability, but it may be annoying when pathnames actually mean something to human beings. Actually with MythTV, I would ignore the "usershare" view completely and just put a separate storage directory on each drive. That's what I do now with my JBOD setup and it works fine. unRAID would add redundancy against single drive failure for me, but no more as I can already add an additional drive/storage directory to MythTV with relative ease. If I cared more about my media files and unRAID was available in my current software, I might use it. I'm probably not going to switch everything around just to start using it. Bill Bogstad _______________________________________________ Discuss mailing list [email protected] http://blu.org/mailman/listinfo/discuss
