Is there are development road map for unRAID?

 

I'm probably just blind but couldn't find on the main website, forum or Wiki.

Unfortunately there isnt one. We  know a few things that are planned but the majority of changes are unknown until they are released.... or rather we can guess at a few things but we have no clue when they are coming.

 

You get used to it

Really? That strikes me as quite an omission for a project of unRAID's scale.

 

On a related note is there any kind of notification mechanism (email list etc) in case critical security/stability bugs are discovered and I need to update?

 

Also does anyone know approximately how many developers there are working on unRAID? I keep hearing about Tom but just wondered what happens if Tom gets ill / bored / run over by a bus.

Really? That strikes me as quite an omission for a project of unRAID's scale.

 

I would agree.

 

On a related note is there any kind of notification mechanism (email list etc) in case critical security/stability bugs are discovered and I need to update?

 

Only the announcement forum here.

 

Also does anyone know approximately how many developers there are working on unRAID? I keep hearing about Tom but just wondered what happens if Tom gets ill / bored / run over by a bus.

 

No one kows for sure but it is likely there is one developer.

Well that's not much comfort! Surely I'm not alone in having these concerns?

 

I get the impression unRAID started off as a small project but has subsequently experienced great success and growth over a small period of time. With so many users reliant on the platform now might be a good time to deal with the points raised above. A road map, mailing list and bug tracker are easy and cheap to to implement and will be pre-requites for larger customers. The issue of 'one developer' on a closed source product is more difficult to resolve, at the very least the software could be open sourced in the event of a catastrophe (sorry Tom - I personally hope to buy you a drink on your 100th birthday).

Well that's not much comfort! Surely I'm not alone in having these concerns?

 

I get the impression unRAID started off as a small project but has subsequently experienced great success and growth over a small period of time. With so many users reliant on the platform now might be a good time to deal with the points raised above. A road map, mailing list and bug tracker are easy and cheap to to implement and will be pre-requites for larger customers. The issue of 'one developer' on a closed source product is more difficult to resolve, at the very least the software could be open sourced in the event of a catastrophe (sorry Tom - I personally hope to buy you a drink on your 100th birthday).

Discussed in this thread: http://lime-technology.com/forum/index.php?topic=4768.msg43854#msg43854

 

Absolute worse case, there are enough of us who could re-engineer the closed source portions.  We would just rather wish lime-tech live long, and prosper... .

OK so Tom has 'act of God' covered - which is great (phew!)

 

What about the other points? Road map, mailing list and bug tracker?

What about the other points? Road map, mailing list and bug tracker?

 

He express some interest a while back in doing something like a bug tracker and maybe a road map, but I can't find the thread right now.

OK well it's good to know LimeTech are at least considering this stuff. I'll wait patiently and see how things develop.

 

I was planning to deploying unRAID servers at some of my clients as they have huge storage needs, however the disaster recovery team are going to ask these questions and won't allow me to proceed without positive answers.

 

I think my exuberance for unRAID in own deployment (home and office) has me thinking beyond the product's current scope. It's just soooo cool :-)

OK well it's good to know LimeTech are at least considering this stuff. I'll wait patiently and see how things develop.

 

I was planning to deploying unRAID servers at some of my clients as they have huge storage needs, however the disaster recovery team are going to ask these questions and won't allow me to proceed without positive answers.

 

I think my exuberance for unRAID in own deployment (home and office) has me thinking beyond the product's current scope. It's just soooo cool :-)

 

Give me a succinct list of what you want to see.

Succinct list:

 

• Road map showing planned development with approximate time scales
  
• Opt-in mailing list for critical bugs / software update availability
  
• Bug tracker
  
• Built-in system event notifications by email (and/or SNMP)
  
• Built-in UPS support
  
• Paid for, per-incident support
  

 

Verbose Explanation:

 

Road map: Shows business users that the software is under active development

Opt-in mailing list: You cannot expect business customers to check your forum daily for critical bugs

Bug tracker: Let's people know what bugs exist and shows Lime Tech's response time

System event notifications: This is a storage appliance, any business will expect notification of disk and power failures as a given

UPS support: Also a given for a storage appliance

Per-incident support: In my experience businesses are more than happy to pay for direct support when they need it. Availability is a pre-requisite for many DR teams (think $100 per hour for parity with other vendors).

 

Any chance a 64-bit kernel option will exist in 5.x? I would think it would speed up parity calculation, especially as disk sizes grow.

Any chance a 64-bit kernel option will exist in 5.x? I would think it would speed up parity calculation, especially as disk sizes grow.

 

No, it would not.  Parity calc takes a very small slice of CPU... it is disk bound, not CPU bound.

I run unRAID on a full Slackware 64bit distro, and as BubbaQ mentioned, the parity calculation itself is not CPU bound at all. Even an old Pentium 3 CPU provides more than enough CPU for the XOR parity calculations.

 

The speed hit when writing comes from the physical media and having to do 4 I/O operations. Those 4 operations are 2 reads and 2 writes; you read the old data and the old parity info then you write the new data and the new parity info.

 

A low power i3 530 can compute the XOR parity at a speed of roughly 10.8 GigaByte per second. A low power Core 2 Duo does roughly 8.6 GigaByte per second. Best of luck finding any drives able to sustain 1/100th of that speed.

 

Dec 23 01:38:39 reaver kernel: xor: automatically using best checksumming function: generic_sse
Dec 23 01:38:39 reaver kernel:    generic_sse: 11156.000 MB/sec
Dec 23 01:38:39 reaver kernel: xor: using function: generic_sse (11156.000 MB/sec)

 

Aug 23 13:04:35 Reaver kernel: md: xor using function: pIII_sse (8863.600 MB/sec)

Thanks. I am a complete unRAID newbie, so bear with me.

 

Would the ability to use more memory be beneficial?

Would the ability to use more memory be beneficial?

 

No.

.... unless you're going to use the box for other things as well as a fileserver...

.... unless you're going to use the box for other things as well as a fileserver...

 

Not likely, since unRAID as it ships has PAE enabled so you can use all the installed memory.  Not much out there that would benefit from flat high memory that would not be equally satisfied with PAE -- particularly anything that would share a box with unRAID.

I think the further we drift from the OT the less likely the original poster is going to get the attention of Limetech.

 

Good discussions but definitely need their own thread

Thanks. I am a complete unRAID newbie, so bear with me.

 

Would the ability to use more memory be beneficial?

unRAID can use "more memory" today.  (and has had the ability for quite a while now)

 

unRAID has the PAE option enabled in its kernel.  It can handle as much as 64 gig of memory.   The additional memory will be used for buffering the disk accesses and no one process can use more than 4Gig of ram.

 

See here for a technical description: http://kerneltrap.org/node/2450

 

Joe L.

 

 

Thank you, and sorry.

 

Watching the Sempron 140/2GB setup in vmstat & top during a massive file copy, where the tar commands are running on the unRAID box moving the data over NFS, it is using all the memory and I see a lot more blocked processes than I like. Regardless performance is impressive, so I will go back to reading.

Your tasks are IO bound.  Check vmstat or mpstat and you will see iowait is high.

 

If you want speed, you need striped RAID.... but you lose flexibility to mix and match disks and easy disaster recovery.

 

If you want flexibility to mix and match disks and easy disaster recovery, then use unRAID.... but you loose performance.

True. I am very satisfied with the performance, just always looking for an opportunity.