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. > 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... Also problematic. > At the block level, they have a single parity drive which is bigger > then any data drive. Interestingly there is no option to add a 2nd parity drive or a hot spare for faster automatic recovery. > 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. One use case they mention for accessing individual drives is if you wanted to permanently remove a drive from the unRAID array and wanted to be able to copy some data off it first onto other drives in the array. That would only be possible if you can address the individual drives. But thats likely a rare use case. If the system is designed well, you shouldn't want to or need to access the drives individually. Apparently you can choose not to export them. > 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. Sounds inefficient, but a file tree could be put in memory, or maybe this is one of the things they use the cache disk for - to store a database of file locations. http://lime-technology.com/wiki/index.php?title=Cache_disk Nope, looks like it is just used as a write buffer. (Also mentioned that you can consider it as a warm spare...though if you need it, what happens to the data that hasn't been flushed?) 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. So the point to the cache drive is that you speed up writes by writing to only 1 drive initially, instead of doing 4 I/O operations to 2 drives, and you save power by having only one drive spun up instead of 2. > A later drive with the same path would be > hidden by an earlier drive. Right, they talk about how directories are merged and how conflicting directories are handled, a problem you would only have if you either used the drives individually before adding them to unRAID, or you made use of their scheme for accessing individual drives. Makes me wonder if they are using UnionFS or borrowed heavily from it. > 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. Actually, per: http://www.lime-technology.com/technology/usershares The two Foobars will get merged, as they are top-level directories. Foobar/baz would not. I'm not sure what the rationale is for merging only at the top level. > 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. This could be a problem if you are storing large video files (the supposed primary application for unRAID) and your array is near capacity. But I guess that is the tradeoff for having individual drives with their own complete file system. > 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? (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,) > ...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. You also need UnionFS functionality, but I don't think it would work to layer them, so perhaps a hacked version of UnionFS. 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. Thanks for the additional research, Bill. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Discuss mailing list Discuss@blu.org http://blu.org/mailman/listinfo/discuss
