Hi,

 

I am a new member and I really like this forum.

UnRAID rocks!! I have 2 questions though:

 

1. Does UNRAID solve Raid 5's write hole bug? If it does not, could a UPS solve the write hole problem?

2. Is it necessary to perform parity checks once a month or something to ensure that no data corruption exists?

3. Does the UNRAID OS support hard disk drives of any size (for example 2TB drives, 3TB drivers ... if they ever show up in the future!)

4. Do you know if Sun Microsystems plans to allow the use of the ZFS filesystem OUTSIDE the solaris OS anytime soon?

 

Thank you very much

 

Does UNRAID solve Raid 5's write hole bug? If it does not, could a UPS solve the write hole problem?

 

No, but the consequences are different (less).  Yes, a UPS is effective ad cheap insurance, and a generally good idea for any system such as unRAID.

 

Is it necessary to perform parity checks once a month or something to ensure that no data corruption exists?

 

Not "necessary" but a monthly parity check is a generally sound practice.

 

Does the UNRAID OS support hard disk drives of any size (for example 2TB drives, 3TB drivers ... if they ever show up in the future!)

 

Yup... as long as the OS supports them and they are smaller than 2^64 bytes (18 million terabytes)

 

Do you know if Sun Microsystems plans to allow the use of the ZFS filesystem OUTSIDE the solaris OS anytime soon?

 

That is not Sun's fault.  ZFS is open source and licensed under CDDL, so anyone can run it under Linux if they want.  The CDDL is not compatible with GNU which prohibits linking with code under certain licenses, such as CDDL, so a stock Linux won't have ZFS.  But you, as a user, can add it easily.

 

... and that was 4 questions.

I see... THANK YOU for the reply!

 

I need some help understanding your answer to the first question that I made! :-)

 

I am not good at understanding all the technology behind the unraid concept... but from what I have understood I believe that the write hole bug occurs when the system writes the data on the drive but "something unexpected takes place" (power failure?) and unraid does not manage to write the "parity" for this data. Is that right?

 

The question is: Is unraid capable of fixing the "inconsistency" between the real data and the parity data if I decide to do the parity check or is this a data loss scenario that can't be fixed?

 

Thanks...

Since parity is written AFTER the writing on the data disk, an inconsistency of the parity data with the data disk, where the data disk has not reported an error, always overwrites the parity thus fixes the parity and all is well again.

 

That is what I know - but I am not the most knowledgeable guy in here (you already talked to one of "them").

 

 

The write hole is when you have a multiple failure:

 

1) the write to data occurs before the write to parity

2) some failure occurs between the write to parity and the write to data

3) either a whole-a disk (other than parity) fails or a stripe read error in the SAME stripe occurs before the parity inconsistency is corrected

 

in RAID5, the stripe is then corrupted.  In unRAID a sector is corrupted.

 

One way (slow) around that is to write the write to a log, then do the disk write, then the parity write, then clear the log.  If the whole thing doesn't complete, you can fix it from the log of the last xaction.  The other way is to have some fault tolerance (i.e UPS) to prevent (minimize) the opportunity for all 2 steps to happen in the first place.

 

Good practice is recalc parity on a periodic basis too.

Since parity is written AFTER the writing on the data disk, an inconsistency of the parity data with the data disk, where the data disk has not reported an error, always overwrites the parity thus fixes the parity and all is well again.

 

Not true.  The data disk write and parity disk write are initiated in parallel & either one could complete first.

 

Yes, unRAID has a potential "RAID-5-like write hole" as described by bubbaQ.  The present solution is similar to other Raid systems solution: if system boots following unclean shutdown, e.g., following power failure or system crash, then Parity-Check operation is automatically started upon restart.

 

But there are other "holes" as well.  For example, Samba will acknowledge writes to the client before disk i/o is even started.  Any pending writes in the server will be lost if unexpected shutdown occurs.

 

The best solution to these problems is a UPS, unless you are an Enterprise with mission-critical data at stake - in this case you buy a $100K system from EMC or Sun which has redundant-everything including controllers that monitor each other.

thanks for clearing this out

(and nice to see you semi-active in the forum again)

 

4. Do you know if Sun Microsystems plans to allow the use of the ZFS filesystem OUTSIDE the solaris OS anytime soon?

 

Apple has announced that ZFS is likely to be in their upcoming Mac OS X server release, due this summer.