[froggit]

I have read the whole thread and it seems like the same concerns regarding Unraid and ZFS reappear quite often. So I will try to explain how they both work from what I gathered through this thread. I have to point out that my knowledge regarding ZFS nearly exclusively stems from this thread. I will edit the information if somebody points out flaws.

Similarities of how Unraid and ZFS function

...<SNIP>

Thanks for that good summary of features beckstown.

I have reviewed your original ZFS section, and made corrections and additions - see below. I am awaiting confirmation that the info in section e) is correct and will update this if it's incorrect:

2. ZFS

a) ZPOOL: With ZFS, on one NAS, you may have one or more 'zpools' (ZFS storage pools). It is usual to have one data spool, however.
Some users also create a separate spool for their Boot Environment, allowing multiple GRUB boot entries, and rollback of a failed OS upgrade if required.
The zpool is the top level component in ZFS storage. A zpool is composed of one or more virtual devices, or 'vdevs' as they are known.

b) VDEV: each vdev may employ varying types and levels of redundancy:
i) stripe with no parity.
ii) stripe with parity: (1) RAID-Z1 = capacity of one drive used for parity (single parity), (2) RAID-Z2 = capacity of two drives used for parity (double parity), (3) RAID-Z3 = capacity of three drives used for parity (triple parity).
iii) mirror using n drives. A drive in a mirror may be removed and read on another system.

c) ZFS can address virtually infinite amounts of data. In fact it's been proven that you would never be able to exceed ZFS' capacity limits: http://blogs.sun.com/bonwick/entry/128_b...ge_are_you

d) To read or write data, drives must be spinning. However, with a home NAS, there are often long periods of inactivity, and this is where the OS power management can be used to spin disks down to reduce power consumption. Faster than Unraid when it comes to read/write of files due to striping/mirrors.

e) Because parity data is distributed (striped) across all RAID-Z1/2/3 vdev drives, ZFS has no concept of a parity drive.
If you lose more drives in a vdev than you have parity, all the data stored in the pool will be lost! This is where backups are important. RAID != BACKUP. Due to this, some ultra-paranoid users insist on use of mirror vdevs, typically a 3-drive mirror vdev, to give the equivalent of double parity, but the added advantage is that drives can be removed and read on another system. However, 3-way mirrors quickly become very expensive for large amounts of data, so are best used only for critical irreplaceable data. And backups should always be done for irreplaceable data.

f) If you create a vdev with drives of different sizes, the smallest drive capacity will be the limit of capacity for the other drives.
Example: If you create a vdev with one 500 GB and three 2 TB drives, you will only be able to use 500 GB per drive. This is why people creating ZFS vdevs use same-sized drives.

g) Adding hard drives: You cannot add hard drives to an existing vdev. Instead, you can create a new vdev and add it your pool.
Example: You have already a vdev with RAID-Z3 and six 2 TB hard drives. This means you have 6 TB of storage and another 6 TB for parity. Now you buy 4 new 2 TB drives which you would like to add to your storage. For this, you have to create a new vdev. The question is then if you still want to use RAID-Z3 for the new vdev as that would mean you would only get 2 TB of new storage as 6 TB would be used for parity. Consequently, you either settle for less parity protection or buy more drives. For example, let us assume you create a RAID-Z2 vdev. So you now have a new vdev with 4 TB of storage and 4 TB of parity. In total you now have 5 disks used for storage and 5 disks used for parity. However, you don't have to lose more 5 disks to lose data. If you lose more than 2 drives on the on the RAID-Z2 vdev, you will lose all of its data. So while there is an additional safety in this setup, it is not as safe as 5 parity drives protecting all the data. Additionally, every time you add a new vdev, you have to pay extra for new parity disks and lose Sata ports due to them. This makes expanding storage more expensive in relation to Unraid.

h) Capacity expansion: As well as adding new drives to expand pool capacity (see g. above), it is also possible to expand an existing vdev by replacing each of its drives, one at a time, and doing a scrub after each drive is replaced. Once all drives are replaced, the new increased capacity is available.

i) Using ZFS snapshots provides protection against accidental deletion of any files. Snapshots are virtually instant and consume no space initially. Snapshots (1) prevent accidental deletion, and (2) allow full and incremental backups to be made to any ZFS-based file system by specifying its IP address. Snapshots also allow a rollback to a last known good state, assuming snapshots are taken regularly.

j) Scrubbing the pool once a month is recommended for home users. A report is displayed giving a list of read/write/checksum errors for all drives within each vdev for the pool. This gives the user clear information about drives which have read/write/bit-rot problems, enabling the user to determine when to replace drives proactively, rather than reactively when it may be too late. Data is still available during a scrub operation, but will be accessed more slowly, but fine for watching movies.

k) ZFS automatically self-heals any corrupted data it reads. Example: you watch a movie that has one or more dropped bits caused by bit rot. When ZFS reads the file, it will automatically detect and correct the corrupted data. This is also done during a scrub operation, which reads all the files and so detects and corrects all corrupted files.

l) Hot spares can be specified when the data pool is created, or added to the data pool later, and are used automatically if drive failure is detected. This minimises the chance of there being two failed drives at the same time, because as soon as a drive fails, it is automatically detected and rebuilt onto the spare drive without user intervention.

m) ZFS data pools can be shared via NFS, SMB/CIFS (Samba) and iSCSI.

n) ZFS has strong mechanisms to help ensure that what you intend to write to disk, is actually what gets written to disk, and read back again later. This is called end-to-end data integrity: http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data