On Tue, Jul 26, 2011 at 2:28 PM, Tom Metro <[email protected]> wrote: > Bill Bogstad wrote: >> It also says that the individual data drives are formatted with >> ReiserFS. > > That doesn't bode well. Not exactly a popular choice these days, having > been mostly abandoned for ext3.
Thanks for your clarifications and corrections to my previous note. > Interestingly there is no option to add a 2nd parity drive or a hot > spare for faster automatic recovery. They are going for customers who are cheap and they are cobbling together random code. This is NOT a datacenter product. It's for people with thousands of ripped CDs/DVDs who don't want to lose everything if a single disk fails in a stripped setup, but also want be able to add whatever random disk they have lying about when they need more storage. >> 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. > > Yeah, I thought that was an odd choice that they exposed that. But you are assuming that they actually did something significant here. I think they did the unRAID block level work and then layered pre-existing software on top of it. The cracks are still visible. > The cache scheme sounds rather hackish. The cache drive gets added to > the union of the file systems, and apparently gets priority for writes. > Then what sounds like a cron job fires off periodically and sweeps the > data over to the protected array. No redundancy protection before that > happens. No attempt to move the data while the array is idle, or > automatically trigger a move when the cache drive is full. See my previous comment on not for the datacenter... > Makes me wonder if they are using UnionFS or borrowed heavily from it. See above. :-) >> It also means that in the "usershare" view a directory subtree can be >> full even if other disks are not. > > Right. If they maintain file system integrity on the individual drives, > that implies that any file you store has to be smaller than your > individual drives, and smaller than the free space on any individual > drive. I wonder how it decides which drive to write to. I would guess that it depends on where ever the parent directory of the file/directory was placed. So once a (sub)directory is placed on a drive everything below that point is forced to that drive as well. >> Actually with MythTV, I would ignore the "usershare" view completely >> and just put a separate storage directory on each drive. > > But would this be any different from letting unRAID choose the drive? Yes. Because MythTV's storage directory setup will use whatever drive has the most space. I think that unRAID makes its decision once (based on where the immediate parent directory was placed and that's it. Bad pathname selection would end up with one full disk and the rest empty. Maybe if you keep everything in a one-level directory tree, this won't be a problem. > (If you have the unRAID overhead, you might as well let it do the work. > Unless read performance would be boosted by having MythTV know which > individual drive a file is on and request it with the direct path,) The only work that it is doing that I want is the RAIDish part (and possibly their data cache). The combined view seems worthless in the context of MythTV. If you manually arrange your file paths, then "usershare" makes everything look on the sufrace like one pile of space, but it really isn't. >> ...I can already add an additional drive/storage directory to MythTV >> with relative ease. > > Drive slots are finite, and what you can't do easily with a JBOD is > replace a populated drive with another one of higher capacity. (Though > easier with a JBOD than a RAID5.) > > Really JBOD + parity is an apt description for unRAID. > > I'm thinking you could accomplish most of what unRAID does with a FUSE > driver that maintains a parity disk. As I understand it, FUSE is at the filesystem level. The unRAID part appears to only be at the block level. It's more like a weird version of the MD/LVM block drivers. You keep parity like RAID4, but you allow direct read/write data access to the individual drives rather then providing a single block device for access to everything. > You also need UnionFS > functionality, but I don't think it would work to layer them, so perhaps > a hacked version of UnionFS. It wouldn't surprise me if the "userview" part is in fact UnionFS (hacked or not). > Reading through the wiki further it also seems that the unRAID approach > is far less automated compared to Drobo. Replacing a failed drive or > upgrading to a higher capacity drive both require several steps to be > performed through the unRAID UI. These ought to be fully automated. i.e. About as easy as replacing/upgrading a drive in a JBOD setup. > Thanks for the additional research, Bill. Ditto. Bill Bogstad _______________________________________________ Discuss mailing list [email protected] http://blu.org/mailman/listinfo/discuss
