osirisjem Wrote:If my UNRAID had a drive that failed, and it is stored in the basement .... how would I know a drive died ?

osirisjem Wrote:If my UNRAID had a drive that failed, and it is stored in the basement .... how would I know a drive died ?

poofyhairguy Wrote:You check on the web interface. I look at both of mine at least one a week.

froggit Wrote: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_bit_storage_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

TugboatBill Wrote:Are you sure you didn't miss anything?

gadgetman Wrote:After reading more about this, i'm even more convinced that those who advocate zfs over unraid for strictly media collecting use ('replaceable' rip/downloaded medias... Not your one-of-a-kind home/work movies) are either unfamilar with unraid or they're employing protections against theoritical catastrophes with very remote chance of occuring.

Quote:Bitrot: very hard to find real stories about it. Theoritical occurence of 1bit every 12TB of transfers (manufacturer's data, hdd spec sheet), which has >99% of occuring NOT on a file's header thus making the file still viewable, with a less than 1/24th second (1 frame of 24fps) glitch in a minute part of the sceeen.

Quote:Multiple drives failure (>number of parity): you should monitor SMART info for early warnings to avoid drive failures due to age (use email autowarnings), and get drives from different manufacturing batches to avoid multiple drives failing together due to manufacturing defects. Worse come to worst, you will lose data only on those failed drives, not your whole raid array like on zfs.

Quote:Performance issues: unless you're running your media server to feed a small motel, then it shouldn't be a problem for simultaneous playback of full hd stream. These systems are generally optimized as write-once-read-many application, so you should avoid doing file processing directly on the nas anyway.

Quote:Protection against accidental file deletion: this should be implemented as 'recycle bin' on samba vfs, so you have fine grain control over every files to check/restore/flush. Zfs snapshots is the wrong tool for this.

Quote:Growth: ... <snip>

froggit Wrote: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:

snip
[/url]

gadgetman Wrote:After reading more about this, i'm even more convinced that those who advocate zfs over unraid for strictly media collecting use ('replaceable' rip/downloaded medias... Not your one-of-a-kind home/work movies) are either unfamilar with unraid or they're employing protections against theoritical catastrophes with very remote chance of occuring.

Quote:you should monitor SMART info for early warnings to avoid drive failures due to age

Quote:Despite those strong correlations, we find that failure prediction models based on SMART parameters alone are likely to be severely limited in their prediction accuracy, given that a large fraction of our failed drives have shown no SMART error signals whatsoever. This result suggests that SMART models are more useful in predicting trends for large aggregate populations than for individual components.

jvdb Wrote:I think it's unwise to make assumptions about other people's reasoning. We all have different experience and knowledge that prompts different decisions. I have seen bit rot on arrays that I maintain--degraded mirrors on 3ware arrays. Granted this has only happened a couple of times, and on drives that see much more use than the ones in my home server. The funny part is that I'm not all that concerned about losing my whole array. The really important stuff is backed up offline/offsite, the rest is replaceable--in fact much of it I would probably choose not to replace.

For me it comes down to this: I can have a free commercial grade solution -or- pay for a consumer grade solution.



Once again, I wouldn't rely on SMART.

http://www.google.com/url?sa=t&source=web&cd=1&sqi=2&ved=0CBIQFjAA&url=http%3A%2F%2Flabs.google.com%2Fpapers%2Fdisk_failures.pdf