Just read this thread -- this is GREAT.

 

Looks like 4.7 will be nearlly "perfect" for those of us who just want a rock-solid, reliable server without a lot of add-ins.    Fixes the ulimit bug & supports advanced format (e.g. WD EARS) drives without a jumper -- the two biggest "gotchas" when using UnRAID with Windows 7 and advanced format drives.    Glad to see the "progress" bars are nearly filled for all of the features for 4.7 ... hopefully that means it will be out SOON.

 

from reading earlier posts i would have suspected the q & p support to have been in 5 beta 3...

seems we will have to wait a long time for double parity support ...

is there no way of prioritizing this ?? after all data security is the main concern for a storage OS ?

 

not complaining though .... just a bit dissapointed 

from reading earlier posts i would have suspected the q & p support to have been in 5 beta 3...

seems we will have to wait a long time for double parity support ...

is there no way of prioritizing this ?? after all data security is the main concern for a storage OS ?

 

not complaining though .... just a bit dissapointed 

I would never have thought that.  Version 5.0 of unRAID is a replacement of the GUI user-interface in ".php" to allow plug-ins, and a re-work of security to allow AFP, NFS, and SMB to work together.  Always was.

 

You are thinking of version 5.3 perhaps, not 5.0beta3.

I'd love to see p + q bumped up the priority list, be such a cool feature.

I'd love to see p + q bumped up the priority list, be such a cool feature.

 

I agree it is a cool feature, and deserves to be implemented.

 

But every time this comes up I feel I have to remind people that dual drive failures have been VERY VERY rare (1 or 2 in the past 3 years).  And even in those situations people were able to to recover their data to a large degree.  And depending on how drives fail, there is still very much the opportunity for P&Q parity to both get screwed up (i.e., if a drive were to fail and return garbage in its dying beaths, both P & Q parity would be updated and you'd still lose data).

 

I would like to see a data layer protection, which would use Reed Soloman techniques (like PAR2 if you are familiar with that from usenet), that would be able to detect and correct data errors.  This, IMO, would be more valuable than the Q parity.

I can see a dual drive failure being very rare, but i'd still love to see it. I don't want to be the one suffering from it

 

I'm familiar with PAR2, something like that would be a MASSIVE benefit to unRAID, really would be a killer feature.

from reading earlier posts i would have suspected the q & p support to have been in 5 beta 3...

seems we will have to wait a long time for double parity support ...

is there no way of prioritizing this ?? after all data security is the main concern for a storage OS ?

 

not complaining though .... just a bit dissapointed 

I would never have thought that.  Version 5.0 of unRAID is a replacement of the GUI user-interface in ".php" to allow plug-ins, and a re-work of security to allow AFP, NFS, and SMB to work together.  Always was.

 

You are thinking of version 5.3 perhaps, not 5.0beta3.

 

HI Joe

 

i guess i got carried away with this post from Tom and with the thread about the driver rewrite

 

http://lime-technology.com/forum/index.php?topic=10021.msg95453#msg95453

 

seemed like things where going quicker then the roadmap was predicting and to be honest today was the first time i ever looked at the roadmap... didn't know the page existed till bgp put the link LOL

I would like to see a data layer protection, which would use Reed Soloman techniques (like PAR2 if you are familiar with that from usenet), that would be able to detect and correct data errors.  This, IMO, would be more valuable than the Q parity.

 

But don't all data drives in the array need to be spinning for writes to a single data drive when using Reed Soloman?

 

For a second parity drive I think a Diagonal Parity scheme can get away with not having all the data drives spinning for updates.

For a second parity drive I think a Diagonal Parity scheme can get away with not having all the data drives spinning for updates.

That is my understanding too.  There was a paper linked to in one of the threads that said exactly that.

He's talking about Reed Solomon error correction not the second parity drive.

So excited - 5 beta 3 is almost complete according to roadmap. Literally can't wait to test it!

I haven't been keeping an eye out on the Roadmap, is Tom updating the beta3 roadmap as he goes? 98% looks pretty close to me.... if it wasn't 98% two weeks ago

 

It was 80 something % last week. Progress is good

The first 90% of the work takes 90% of the time. The last 10% takes the other 90% of the time.

 

I hadn't even thought about this kind of approach. What a great idea!

 

I'd love to see p + q bumped up the priority list, be such a cool feature.

 

I agree it is a cool feature, and deserves to be implemented.

 

But every time this comes up I feel I have to remind people that dual drive failures have been VERY VERY rare (1 or 2 in the past 3 years).  And even in those situations people were able to to recover their data to a large degree.  And depending on how drives fail, there is still very much the opportunity for P&Q parity to both get screwed up (i.e., if a drive were to fail and return garbage in its dying beaths, both P & Q parity would be updated and you'd still lose data).

 

I would like to see a data layer protection, which would use Reed Soloman techniques (like PAR2 if you are familiar with that from usenet), that would be able to detect and correct data errors.  This, IMO, would be more valuable than the Q parity.

But again, I'll point out that with Reed Soloman I don't think you can spin down all drives but the parity and data drives you are writing to.  It is my understanding that all drives in the array must be spinning for writes with Reed Soloman, where with diagonal parity you only need the parity drives and the data drive you are writing to spinning.

 

Reed Soloman may well be worth having all drives spinning for writes -- but, if my understanding is correct, I think this potential negative merits discussion.

 

I hadn't even thought about this kind of approach. What a great idea!

 

I'd love to see p + q bumped up the priority list, be such a cool feature.

I would like to see a data layer protection, which would use Reed Soloman techniques (like PAR2 if you are familiar with that from usenet), that would be able to detect and correct data errors.  This, IMO, would be more valuable than the Q parity.

 

But again, I'll point out that with Reed Soloman I don't think you can spin down all drives but the parity and data drives you are writing to.   It is my understanding that all drives in the array must be spinning for writes with Reed Soloman, where with diagonal parity you only need the parity drives and the data drive you are writing to spinning.

 

Reed Soloman may well be worth having all drives spinning for writes -- but, if my understanding is correct, I think this potential negative merits discussion.

In my mind "diagonal parity" has a huge advantage there.  I see no downside.  Most unRAID users would not want all the disks spinning.

 

Joe L.

Most unRAID users would not want all the disks spinning.

Indeed this power saving feature is a huge advantage over other traditional NAS designs, and is a key selling point.

Most unRAID users would not want all the disks spinning.

Indeed this power saving feature is a huge advantage over other traditional NAS designs, and is a key selling point.

assuming its only for writes and adds protection against bit-rot (like par2) that would taht not be a price worth paying?

If there was a way to detect and repair bit rot all the ZFS guys would be out of ammunition against unRAID

BTW, 5.0-beta5 should be posted later today  

 

Is the Roadmap being updated?  There is no mention of a 5.0b5 on the Roadmap, and actually 5.0b3 is only at 98% completion, with nothing done for 5.0b4.  I'm confused.  

Same question, looked really good to know where Lime is with things, but stopped at 5.0 beta 3? Clearly Lime is up to 5.0 Beta 6a?

And is Roadmap for version Never as in NEVER 

I'd love to see p + q bumped up the priority list, be such a cool feature.

 

I would like to see a data layer protection, which would use Reed Soloman techniques (like PAR2 if you are familiar with that from usenet), that would be able to detect and correct data errors.  This, IMO, would be more valuable than the Q parity.

 

Still same issue applies, how do you generate the PAR2?

 

You generate the P+Q parity with the data on the disks, you generate parity + PAR2 with the data on the disks.

 

If the data on the disks is corrupt then you have the corrupt file on the recovery disks too, however you do it.

 

Only *real* way of ensuring data integrity is that you regularly compare original to the backup in form of md5 hashes etc.

 

However, I've never come across a disk which actively corrupts data without some sort of error to go with it.

 

One of my WD20EARS just died without warning, another disk just used to stall reading some files, never had a disk corrupt something during failure!

Is there an actual estimated release schedule floating around here somewhere?

 

Reading this "roadmap" which was posted on January 1st, 2011, there are subsequent posts that suggested that the release of 5.0 would be out in approximately 3 months (March-April timeline) and 5.1 out in 6 months (June-August timeline).

 

It's now almost June and 5.0 has been (and still is) in beta for seemingly ages.

 

As a developer myself, I understand how certain projects and new features may actually be more difficult to implement than first estimated, but I'm a single shareware developer.  Lime-Technology is a commercial operation so I am assuming there are plenty more resources available on-hand to tackle these projects.

 

Its just as a paying customer, it would be nice to be given at least rough timelines of product updates, even if it ends up being delayed (with appropriate reasons provided, of course).