gadgetman Wrote:Pros/Cons

poofyhairguy Wrote:ZFS
-Far more robust than hardware RAID solutions while delivering equivalent performance
-Includes real time protection against "bit rot."
-Allows you to put together many arrays (called vdevs) into a single storage pool. This allows you to customize how much redundancy you have and optimize a solution for your situation
-Can have up to three parity drives
-Faster than Unraid on writes and reads, sometimes by a large amount
-Array can be moved to any system that support ZFS, and therefore is no OS dependent
-Designed for corporate use, so has some real money behind it
-Yet can be used by freely available OSes like FreeBSD
-Downsides include: data is striped so data on drive can't be read on other computers, you must use the same size drives or you waste any space larger than the smallest drive in the vdev, and when data is accessed from a vdev all the drives in that vdev spin up because of the striped data
-Best Uses: Servers with some important non-media data. Mediaserver with many (4+) clients, anything commercial, places where you would usually use RAID 5/6 (basically ZFS makes those RAId levels obsolete).

Unraid
-Allows you to mix and match drives of different sizes and makes into a single array of pooled storage
-Allows you to pull the drives of the array out and read the data on them on another computer
-Allows drives to spin down if they are not being accessed, saving power and possible prolonging their life
-Unraid allows for the growing of the array in size by replacing one drive at a time with full use of that drive after addition and no data loss
-Downsides include: Unraid costs money for real versions, Unraid's write speeds are pretty low without a cache drive, Unraid's read speeds are slightly lower than the drives by themselves, Unraid has no protection against "bit rot," Unraid relies on its OS based on the primitive Slackware Linux, Unraid currently only allows for one parity drive
-Best Uses: A media server that is grown periodically as storage is needed, one cheapest disk available at a time.


How about that?

gadgetman Wrote:@froggit: not to belittle any potential problem, but correct me if I'm wrong here: the possibility of bitrot happening is far less than a drive failure, within the same amount of time.

Not to mention, bitrot should not happen on read-only access on drives- which is like 90% use of media content servers.

harryzimm Wrote:Nice comparisons guys. It's good to know that some people can see the positives in other than what they have chosen for their own setup. Stop taking this so personally (froggit). I think the amount of research you have put in has clouded your judgment. Take a step back once in a while. You don't need to prove your setup works for you, we believe you.

cheers

darkscout Wrote:Why does everyone keep saying this? It's not true. True, with ANY RAID (even unRAID) you're going to get better performance with matched drives. If you have mismatched drives, you either give up security or space. I have mismatched drives right now for my Xen virtual disks.




You seem to be confused. You can't expand a vdev. You can certainly expand pools. You should read up a bit more on how they all relate. If you have 14TB of data and want to expand the system, all you need to do is slap more drives into a vdev then add the vdev to the pool.

And giggity. I just re-read the Wiki. ZFS is in GNU/kFreeBSD. So that's yet another option.

froggit Wrote:It was the research I did that led me to considering usage of ZFS: it was right for me because I did *almost* lose a lot of irreplaceable data, and I said 'never again'.

But I accept other people will use whatever they want, and of course, that is fine, I just wanted to throw ZFS into the discussion to show that it is another strong contender, and let others decide on whatever they want, armed with some facts about ZFS etc. Try not to get so uptight if someone else tries to show some other solution backed up by some data and facts. No flames please. As you said, let's move on... it seems we are now moving onto creating a useful wiki of pros and cons of the various solutions suggest here in this thread, and I think that is a very useful and practical outcome?

froggit Wrote:unRAID:
-Allows drives to spin down if they are not being accessed, saving power and possible prolonging their life (but what about spin-up/down wear and tear on drive components?)
Downside include: when a non-parity drive dies you will probably lose all data on that drive, unless you are able to recover it using tools like (name them here or point to recovery URL perhaps?), or you have backups. In case of data loss you will need to use backups if you have them, or re-rip your media from original media.

harryzimm Wrote:I agree, Lets make this thread as useful as we can. Sorry for picking on you , hopefully the wiki and xbmc users will benefit from this discussion.

cheers

poofyhairguy Wrote:[quote=froggit]Sounds pretty good poofyhairguy. After reading it, my suggested additions/changes are below - what do you think?[/quotes]

Looks good overall.



I think mentioning the open source nature of ZFS is important.



Very true, good point. My wife still hasn't gotten completely used to the extra three seconds it takes to spin up a drive when she clicks on something in XBMC.



Again good point, two sides of the same coin I guess.



That needs to be changed to "when two non-parity drives die at once you will lose the data on those drives" but otherwise looks great!

maxinc Wrote:I think you must be confusing unRAID with something else because none of that applies to unRAID. What would be the purpose of a parity drive if not for offering redundancy in case one of the non-parity drives decides to die one day?

froggit Wrote:What happens if one non-parity drive dies?