stricter hardware requirements for unRAID?

relevant "5.0 final" announcements thread here: http://lime-technology.com/forum/index.php?topic=25611.0

 

in the thread linked above, Tom mentioned some new cool features for future versions of 64-bit unRAID which could potentially be really awesome. several have already brought up that changes which are exclusive to a 64-bit hardware could hurt a lot of current unRAID users since they still have 32-bit rigs.

 

now, based on what I've seen in the forums, it appears that the "slow-write" problem (holding back 5.0 final) as well as the infamous Realtek NIC issue have been significant hindrances (among others) to a speedy release of version 5.

 

with all this in mind, i'd like to hear the community's your thoughts on these questions:

• what if there were stricter hardware requirements for future versions of unRAID?
  
• if it led to faster development or better 'official' support, to what extent would it be an acceptable change for you?
  
• what types of hardware do you consider reasonable to compromise on (or not at all)?
  

[...] I think there comes a time when you have to be quite ruthless and say it is time to move on, and only support hardware/configuration XYZ. I mean, the people that are saying they are going to be left behind with non compatible 32bit hardware.... this is 2013. I would hazard a guess that the majority of people that post here and are into unraid can pluck up some money to afford a 64bit compatible board/cpu. You can buy an old system that would be suitable for less than the cost of an unraid licence I suspect. If we keep trying to support everything and make unraid so universally compatible, it will never move on. If the slow write issue is because of running more than 4gb of ram. I think 5 should be released and specified as only compatible with 4gb max of ram. Ram is cheap. Worst case is some people have to buy a couple of sticks to facilitate their needs. Anymore problems with crappy realtek nics for example should be met with a reluctance to keep supporting them and only Intel NICs supported. I say this owning a board WITH a realtek NIC.

 

I am finding it a bit disappointing to keep seeing RC after RC and then after a few posts a statement from Tom like "fixed in next RC". It feels like this will continue forever right now. [...]  It just feels like we say this a lot. "Just one more..."

 

i wholeheartedly agree with jaybee's statement. i dont want hardware compatibility fixes to stifle development so much that it hinders unRAID's viability as a lifelong storage solution for me. i'm talking about unRAID - the software product, NOT an unRAID System (the collective hardware and OS you assembled at home). software companies place constraints on end users all the time and they routinely retire support for older hardware systems.

 

personally i dont really mind being "locked in" to a particular set of hardware compatibility guidelines, as long as those guidelines are defined *before* i purchase a license and they dont dramatically alter the usability of the software for me.

 

those who are unwilling/unable to meet hardware compatibility requirements for future releases (like 64 bit or Intel-only NICs) lose nothing except the ability to enjoy future-version-exclusive-features. the fact that these new features are all completely FREE and that Tom doesn't charge for new versions goes a long way in my book. it's not like i'm paying for a subscription/service.

 

unRAID has added so much security, stability, and enjoyment to my life that i would gladly give up the luxury of using a particular NIC (or processor series or mobo or SATA chipset) in order to continue reaping the benefits of such great software. not everyone will agree with this - just my opinion.

 

what are your thoughts?

Well.... Actually... When I builded my present system I would have welcomed a shopping list stating "just get this and will be your optimum set"...

 

On the other hand, great thing of unraid is that it can run on old stuff you have lying around..

Just remember that which ever hardware is recommended it is only available for so long till it stops being produced. So the recommended hardware list would have to be a constantly evolving list.

 

There is a hardware compatibility, located here: http://lime-technology.com/wiki/index.php/Hardware_Compatibility

 

But it is/becoming out of date. In theory buying anything on that list that is "level 3" tested you will be good to go. For even more assurance you can get the "official Lime Tech recommended board"

 

 

good point, it would probably be burdensome to maintain a really detailed, evolving list of "what works" with unRAID.  i guess instead of having specific brands/models such a guideline would have to be broad enough to cover a family of devices/products (eg, only Intel chipset NICs will be 'guaranteed' to work)

 

my larger concern is with current unRAID users who might would be be opposed to a hardware standard for future releases. my guess is most current license holders would be okay with it.

 

say for example, version 6 of unRAID was to be 64-bit only (people can go on using older 32-bit versions all they wanted, but Tom would only need to 'support' the 64-bit version in his coding/testing/development.

 

from where i stand, it's like this:

Option A: Get a new software release from Tom, wait for the unRAID 'power users' with non-prod systems to test it, provide feedback on the forums, wait for LimeTech to come up with a coding solution, code it, test it, release it, and then repeat the entire process again.

Option B: i got out and buy/borrow/trade a $19 NIC that is known to work perfectly fine (because it matches the hardware LimeTech recommends/uses for their testing)

 

am i oversimplifying it?

good point, it would probably be burdensome to maintain a really detailed, evolving list of "what works" with unRAID.  i guess instead of having specific brands/models such a guideline would have to be broad enough to cover a family of devices/products (eg, only Intel chipset NICs will be 'guaranteed' to work)

A list like that exists in the wiki..  Problem is, any given hardware very quickly goes out of date. )

am i oversimplifying it?

Yes, because even a LimeTech supplied hardware list will not suit many needs.

 

Example...

                o -  My first server's Intel MB is PCI only, and not 64 bit capable. 

                      (granted, it was the standard 8 years ago)

                o - The superMicro C2SEE on my second unRAID server works fine, but I've never been

                      able to get it to wake up after being put to S3 sleep. 

                      Tom at lime-tech does not support putting the server to S3 sleep,

                      so if you need that capability, too bad. 

                      If your MB works with that feature, great... some do, but others do not.

 

Both were the recommended motherboard at the time I built those servers.  Both were the exact board Tom used in his hardware he was selling at the time, in fact Tom built my first server (I purchased it assembled 8 years ago)

 

No hardware list will do for everyone, and certainly not for long.

 

Joe L.

o - The superMicro C2SEE on my second unRAID server works fine, but I've never been

                      able to get it to wake up after being put to S3 sleep. 

                      Tom at lime-tech does not support putting the server to S3 sleep,

                      so if you need that capability, too bad. 

                      If your MB works with that feature, great... some do, but others do not.

 

Suspend/wake has always been 'iffy' on Linux. Sometimes you can get it to work perfectly well ... until a kernel update comes along - at which point the suspend/wake simply stops working.

I am with the other posters. Fundamentally a supported list is a good idea. The problem is you have to go one of two routes:

 

1. Server class hardware

 

So Supermicro boards etc are brilliant but you pay a premium for what you get. Also if you dont need IPMI etc this premium is debatable not worth it. More importantly availability is not global and often even if you can source the kit its MUCH more expensive. For example for me to source a Supermicro board in a short period I will be paying close to double what my USA counterparts pay.

 

2. Residential class hardware

 

For me this is the way to go. Bang for buck is excellent but your lucky if you a motherboard etc stays available to buy for 1 year. We could potentially cover this by going to the higher end of this class of hardware where boards tend to be branded and when deprecated are done so with an obvious replacement. e.g. AsRock Extreme 6,7 etc

 

But the golden question is whom is going to commit to buying and testing these things. Its doubtful Limetech would want to which means the community would need to do it.

 

That would be unreliable at best

For example for me to source a Supermicro board in a short period I will be paying close to double what my USA counterparts pay.

 

Try buying that kit here in Philippines!  Can you imagine how much my X9SCM-iiF cost me after I pay the US street price, then pay shipping, then pay taxes and duties?

 

We could potentially cover this by going to the higher end of this class of hardware where boards tend to be branded and

 

... use a Realtek NIC chipset.

 

when deprecated are done so with an obvious replacement. e.g. AsRock Extreme 6,7 etc

 

... sometimes.  For my original build I chose an Intel board, using an e1000 chipset.  Now Intel have announced that they're no longer going to produce consumer-level mobos!

 

unRAID is a server product, and deserves server-level hardware.  Many people need such features as IPMI because their server is housed in the basement/attic etc.  Also, ECC memory is desirable in a server build - how many consumer-level boards support it?

Seems unlikely to happen,  Is Tom really likely to want to buy half a dozen motherboards and test them every 6-12 months?  Even then manufacturers do new revisions of boards,  different bioses etc.  Without seriously restricting the hardware list there are too many variables imho.

I would be interested in why unraid is so susceptible to this issue. You can generally chuck a linux distro on any old thing and so long as there is driver support it works.

 

unraid seems to be far and away the worst 'distro' I've ever used on any hardware for being picky about requirements. It's even worse than x86 solaris! I don't know why given it should be sharing the same kernel. Would other distros genuinely reveal the same problems that unraid has? It is the reduced subset of drivers included in the unraid kernel causing issue? Is it the rewritten md drivers code interaction with devices that is the problem? Too bleeding edge on kernel releases?

 

I genuinely don't get why unraid has so many hardware issues. A lot of the hardware used across the forum isn't very odd - and other people are running similar mixes on 'normal' distros with snapraid / flexraid etc etc without anywhere near this level of fuss.

 

A provided supported hardware list would be nice - it doesn't mean that's all anyone has to buy - just that you're on your own if you deviate. Given the release movement of unraid the worry would be that the hardware list would move too slowly though.

 

 

...

unRAID is a server product, and deserves server-level hardware.  Many people need such features as IPMI because their server is housed in the basement/attic etc.  Also, ECC memory is desirable in a server build - how many consumer-level boards support it?

 

To be fair uNRAID is a low end server product to fit a nieche home market. For most people a low end bargain bucket modern MB will perform just as well as a high end server motherboard. I dont disagree that the better the hardware you throw at it the better but we have to be sensible here.

 

For instance I have in front of me as we speak a million bucks of brand out of the box new Cisco, HP and EMC server kit. Should I ask Limetech to support it no obviously thats a silly extreme example but its the other end of the scale.

 

IMHO this "stricter hardware requirements for unRAID" is not going to happen unless one of the unRAID resellers take up the challenge. That isnt beyond the realm of possibility though and is possibly the way this thread should go.

 

this approach could work if the unRAID community (or a small portion of native country users) sourced their kit from these resellers making it a financially viable for them to do the work... and the rest of the planet that cant justify massive shipping costs can benefit.

 

anyway its a thought

My thought is although unraid is a server os, its greatest strength is the ability to use it on consumer hardware or just hardware laying around.

 

I think the incompatibility is being a little exaggerated. Realtek nics can be iffy, but all it would take is a bad driver update and Intel nics can be as well. The fact of the matter is most boards have realtek nics. Plus the nic issue is peanuts compared to other issues. A different driver for the affected chipset and all is well.

 

As for 64 bit vs 32, I think the move would be beneficial. The older servers could still run on the version they are on, but would not get new features. Happens all the time in the tech world. And they are still doing the job they were bought for. No tech is considered lifetime, sooner or later it will need to be upgraded. I'm sure many users went and bought the iPhone 5, and it will still do what they want when the iPhone 6 comes out, but if they want that new feature.... Time to upgrade. And might I add, that iPhone Costs as much if not more than a lot of the unraid servers out there. I know I built mine for half the cost.

 

It's not like dropping 32 bit support is going to cause your server to stop functioning.

I would be interested in why unraid is so susceptible to this issue. You can generally chuck a linux distro on any old thing and so long as there is driver support it works.

 

unraid seems to be far and away the worst 'distro' I've ever used on any hardware for being picky about requirements. It's even worse than x86 solaris! I don't know why given it should be sharing the same kernel. Would other distros genuinely reveal the same problems that unraid has? It is the reduced subset of drivers included in the unraid kernel causing issue? Is it the rewritten md drivers code interaction with devices that is the problem? Too bleeding edge on kernel releases?

 

I genuinely don't get why unraid has so many hardware issues. A lot of the hardware used across the forum isn't very odd - and other people are running similar mixes on 'normal' distros with snapraid / flexraid etc etc without anywhere near this level of fuss.

 

A provided supported hardware list would be nice - it doesn't mean that's all anyone has to buy - just that you're on your own if you deviate. Given the release movement of unraid the worry would be that the hardware list would move too slowly though.

I wonder the same thing about seeming h/w instability.  It's not due to the 'unraid' driver because it's just a "layered driver" sitting on top the normal disk drivers.  This can cause other problems but not h/w related ones.

 

Here are my thoughts on the matter:

 

a) Many, probably most, h/w related issues have to do with, well, bad h/w.  You would think "server class" stuff would be better than "consumer class".  This might have been true a dozen years ago, but honestly, it's all made in the same factories with the same parts.  Maybe server class gets more testing, but I don't know if this is true across the board.

 

b) Related to a), bad h/w can be very difficult to pin down, especially something like a bad PSU that is say, producing marginally high ripple on the +12V line happening to combine with a particular hard drive marginally too susceptible to ripple on +12V.

 

c) As for linux, yes, we are probably building far larger disk storage systems than 95% of the linux users out there.  This is going to stress both h/w and s/w.  The enterprise linux guys ameliorate this by sticking to one kernel release longer, having more control of h/w platforms supported, and having large support staff to chase down problems.

 

d) The other issue I see with linux is this:  (First let me preface by saying I have a great appreciation and respect for linux and all the developers who have brought linux to where it is today.)  Have you followed the rate of linux kernel releases in the last year or two?  It is simply not possible to test everything given that rate of release.  Lots of bugs do get through IMHO.  The linux development model relies on the individuals who wrote the code are also the ones who test it, and for a lot of the subsystems it's a labor of love and not much money.  And if something is wrong, they are motivated by love to fix it most of the time.  Also, the driver error recovery stuff could be better designed but that's another subject...

 

Back to question of the thread.  It is simply not possible for me to maintain a "supported hardware" list.  The support of the Community is required for this, and so far, has been pretty good, for which I greatly appreciate.  I really like how many posters include their h/w rig in their forum signature;  I think this helps a lot.

I agree a "supported hardware" list isn't realistic, but a better maintained known bad hardware list could be useful.  As far hardware issues go, I very much appreciate Tom's work getting the Realtek NIC drivers included, given how common they are on motherboards.

The problem really is that all these ideas require a small group of people to maintain documents (i.e. efort).

 

This might work short term but I cant see any approach where someone isnt getting paid for it surviving through the years.

 

However we could look at this an other way. Starting from 5.X we could allow, require, inspire a user to enter system details in their emHTTP. By inspire I mean on the emHTTP homepage have some data fields that stick out if they are not completed.

 

If we can get users to spend a couple of minutes once to enter these details for their own systems (which is of benefit for themselves so likely would happen) then we can have an anonymous system reporting mechanism.

 

i.e. Limetech collects basic anonymous system stats and creates a chart. It is likely that this chart would at least give users a roadmap to components that are popular. This mechanism could be extended later if it is successful to include a rating system.

 

The key here is that it is front loaded effort but little effort going on and the system would self populate i.e. work for a long time.

 

There are other side benefits such as getting an idea of how many people have 32bit only CPU, how popular device X is and therefore how much dev effort should be applied etc

If we can get users to spend a couple of minutes once to enter these details for their own systems

 

How much of this information can be collected automatically?  It seems to me that a lot of the information already appears in the syslog.

 

Oh, and if the data is to be harvested, the user have to be given the opportunity to opt-in (or opt-out?).

How much of this information can be collected automatically?  It seems to me that a lot of the information already appears in the syslog.

 

There is some data that is easy to get automatically and beneficial to do so e.g. CPU, RAM

 

There is other data that is hard to get automatically e.g. Motherboard

 

There is data we never want to get automatically e.g. RAID cards. Otherwise we would collect the Linux name for these devices and not the brand name (likely we want both)

 

There is other data which prople may consider sensitive e.g how much HDD space you have and have used but same people might be happy submitting a summary of different disks seen e.g. seen WD RED 2TB and not I have 20TB of WD RED 2TB

 

The trick is to keep this as simple as humanly possible otherwise it is never going to happen.

 

Oh, and if the data is to be harvested, the user have to be given the opportunity to opt-in (or opt-out?).

 

I would suggest a button to submit anonymously. i.e. manual opt in

 

 

Update: Actually saying all this dmidecode if added could likely do all the heavy lifting

Update:

 

2 minutes with bash and dmidecode gives me this as a sample proof of concept output

 

Motherboard
=======
ASRock
H61M-HVS
P1.30

Memory
=======
        Size: 4096 MB
        Size: 4096 MB
        Maximum Capacity: 16 GB

CPU
=======
Intel
Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz
3100 MHz
                64-bit capable

 

Note this is on a random Ubuntu system not unRAID but it proves the concept.

 

Imagine you are looking to buy a new system and you could search the uNRAID hardware database for components and see xx people run it or similar.

That's a great idea - unfortunately it won't capture the hardware detail of us virtualised users very well, but certainly should work well for everyone else.

That's a great idea - unfortunately it won't capture the hardware detail of us virtualised users very well, but certainly should work well for everyone else.

Sorry, but if you are advanced enough to set up virtualization, you are tech savvy enough to do the legwork yourself. Part of the allure of virtualization is another layer of hardware independence, so theoretically you can move virtual machines to new hardware much easier anyway.

2 minutes with bash and dmidecode gives me this as a sample proof of concept output ...

 

Clearly, dmidecode makes it much easier, but I can already get some of that info from the syslog (or dmesg):

 

Supermicro X9SCL-II/X9SCM-II/X9SCL-II/X9SCM-II, BIOS 2.0a 09/17/2012

Memory: 8248852k/9175040k

CPU0: Intel® Xeon® CPU E31230 @ 3.20GHz stepping 07

LSISAS2008: FWVersion(14.00.00.00), ChipRevision(0x02), BiosVersion(07.27.00.00)

- Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 02)

RAID bus controller: HighPoint Technologies, Inc. Unknown device 0620 (rev 01)

Ethernet controller: Intel Corporation 82574L Gigabit

Yeah you sure can but it has some limitations not least of which means it can only be run at boot.

 

I would suggest a more positive scripting approach would be more reliable. We can query proc etc but at some point we might as well leverage the ongoing work of the dmidecode people.

 

The details of implemantaion can come later once the heavy hitters decide the concept is viable.

 

Obne ting i will say though is this has to be native or a plug-in that is installed by default. If we put a install hurdle in the way we defeat the point.

NAS Brilliant idea.

 

Perhaps some sort of 'report' page that reported hardware in a normalized manner along with a check box to post the syslog when problems were found.

 

If there was some general area that could accept the normalized hardware report along with syslog, it could be reviewed automatically for statistics and provide a syslog for problems when limetech and the community need to be involved.

 

 

I think it might be a solution to this problem and others we havent thought of yet. It also doesnt sound like a lot of work.

 

One thought I had is it might be better to share a complete dmidecode dump that has been anonymized i.e. serial numbers removed.

 

The reaosn I say this is that if i run:

 

dmidecode -t 9
# dmidecode 2.11
# SMBIOS entry point at 0xbf63ac98
SMBIOS 2.7 present.

Handle 0x0008, DMI type 9, 17 bytes
System Slot Information
        Designation: PCIE1
        Type: x16 PCI Express
        Current Usage: In Use
        Length: Long
        ID: 17
        Characteristics:
                3.3 V is provided
                Opening is shared
                PME signal is supported
        Bus Address: 0000:01:01.0

Handle 0x0009, DMI type 9, 17 bytes
System Slot Information
        Designation: PCIE2
        Type: x1 PCI Express
        Current Usage: Available
        Length: Short
        ID: 18
        Characteristics:
                3.3 V is provided
                Opening is shared
                PME signal is supported
        Bus Address: 0000:02:1c.0

 

we could get to the point of it being able to answer questions like:

 

"Tell we a system that people use i3 CPUs on, has more than 10 users and at least 3 PCIx8".

 

That point is just data analysis and is likely a ways off but it is not a stretch.

Overall, I think Tom has it right working out the issues with the Realtek network support. There are just too many boards using that hardware to say "sorry not supported". One feature of unRAID is that it has to be easy to use and having no network driver support for what seems to be the vast majority of consumer motherboards these days isn't the way to go. A similar thing can apply to other common hardware.

 

 

I think having a system in place for polling the system data could work to help build a database of working systems.

 

I have to say that having people enter data is a lousy idea. There are too many people who will do it wrong. I'm sure anyone who's been involved in customer service or any other field where they rely on receiving information will attest to how often the information ends up wrong or incomplete. You'd end up with a database with many different "variations" of the same component.