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:Sounds pretty good poofyhairguy. After reading it, my suggested additions/changes are below - what do you think?[/quotes]

Looks good overall.

Quote:-Yet can be used by freely available OSes like FreeBSD, OpenIndiana/Illumos, Linux* (* http://www.osnews.com/story/23416/Native_ZFS_Port_for_Linux)

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

[quote]
Spinning drives is also a pro as it gives faster access because you don't need to wait for drive(s) to spin up.

Quote:(but what about spin-up/down wear and tear on drive components?)

Quote:Downside include: when a non-parity drive dies you will probably lose all data on that drive

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?