The referenced thread has a few relatively novice users that have little experience with unRAID.  I'm not sure I would be 100% sure that it is fully working.

 

Also, remember every time there is an update to a new version of Linux, you run the risk of having problems.  A standard motherboard goes through testing cycles at LimeTech labs.  That is worth a lot to me.

 

Go for the SuperMicro board.

 

 

I think this is one of the very few times I have a (friendly) disagreement with Brian and NAS.  It's not that his recommendation of the Super Micro is wrong, or that using the Lime tested boards is not a smart choice, but that it undermines one of the unRAID advantages.  I like to think of unRAID as being widely compatible with almost all hardware, at least whatever the latest Linux kernels can support.  It's not, because Tom at Lime Technology keeps it a stripped down distro with support mainly for mainstream hardware appropriate for most unRAID users, so for example, there's no support for graphics, hardware RAID controllers, rarely found components, etc.

 

So although it *may* be in the best interests of a prospective board buyer to choose from an extremely limited set of well-tested boards, I don't believe it *should* be that way.  And I don't see that much difference between the modern boards, once you have eliminated a few faulty board families, and once at least one user has confirmed support for the chipsets of a particular board under consideration.  Otherwise, you are likely to give off the impression to 'outsiders' and critics that unRAID is only compatible with a very limited set of hardware.

 

And motherboards come and go so quickly.  A specific recommended board can disappear in half a year.  Chipset families last much longer.

 

Philosophically, limiting our choices does not feel right.  I would rather shoot for wide compatibility, and wherever we find an issue, work to increase compatibility, rather than decrease our choices.  In practical terms, there is not much we can ourselves do to increase compatibility, other than push for it, but it still feels like the right course.

 

Some computer components have become so standardized, they are commodities.  Perhaps more should.  Once fully standardized, compatibility becomes a non-issue.  I'd like to see hardware compatibility lists become obsolete.  Probably won't happen, but it is still a good direction to go.

Is there any reason to believe that I will lose my data by shifting the drives to a new mobo?!?!?

 

No, no problems, unRAID boots each time as if it had never seen your hardware, and builds a kernel tailored to that machine's specific chipsets, controllers, and drives.  You should check the drive assignments, especially make sure the parity drive is correctly assigned, and then run one parity check to ensure complete validity of the array and its parity info.

 

The above was written based on the normal situation, of moving drives and flash to a new system.  Your situation is a bit 'special'!  You will have incorrectly calculated parity bits, so you WILL have parity errors/corrections the first time you run a parity check on the new machine.

 

One more possible problem, the nForce data corruption issues often resulted in minor corruption in files.  The corruption is usually just a few rare bits, depending on the frequency of the data corruption issue.  I recommend file compares with the original files copied, or archive tests, such as the zip integrity self-test.  On my machine, the errors were roughly one wrong bit per gigabyte, doesn't seem like much, but completely destroys your confidence in the data integrity of your array.

  I recommend file compares with the original files copied, or archive tests, such as the zip integrity self-test.  On my machine, the errors were roughly one wrong bit per gigabyte, doesn't seem like much, but completely destroys your confidence in the data integrity of your array.

 

That will be tough since some of these files are unique to my storage array. I had a fair amount of confidence, so this is where I stored the files. I can only hope that the corruption rate is both very low and on files that can suffer that (ie mp3's and avi's). If you have to have copies of your copies of your RAID5 stored "safe" copies, then what's the point? I know all about 5 9's as I work in that software arena all the time. My data isn't that critical or I would have taken more precautions, but I did place some trust in my unRAID array maybe pre-maturely. Let's hope strongly for that non-destructive parity check in a near future release....Tom?

 

cheers,

Paul

I think this is one of the very few times I have a (friendly) disagreement with Brian and NAS.  It's not that his recommendation of the Super Micro is wrong, or that using the Lime tested boards is not a smart choice, but that it undermines one of the unRAID advantages.  I like to think of unRAID as being widely compatible with almost all hardware, at least whatever the latest Linux kernels can support.  It's not, because Tom at Lime Technology keeps it a stripped down distro with support mainly for mainstream hardware appropriate for most unRAID users, so for example, there's no support for graphics, hardware RAID controllers, rarely found components, etc.

 

So although it *may* be in the best interests of a prospective board buyer to choose from an extremely limited set of well-tested boards, I don't believe it *should* be that way.  And I don't see that much difference between the modern boards, once you have eliminated a few faulty board families, and once at least one user has confirmed support for the chipsets of a particular board under consideration.  Otherwise, you are likely to give off the impression to 'outsiders' and critics that unRAID is only compatible with a very limited set of hardware.

 

And motherboards come and go so quickly.  A specific recommended board can disappear in half a year.  Chipset families last much longer.

 

Philosophically, limiting our choices does not feel right.  I would rather shoot for wide compatibility, and wherever we find an issue, work to increase compatibility, rather than decrease our choices.  In practical terms, there is not much we can ourselves do to increase compatibility, other than push for it, but it still feels like the right course.

 

Some computer components have become so standardized, they are commodities.  Perhaps more should.  Once fully standardized, compatibility becomes a non-issue.  I'd like to see hardware compatibility lists become obsolete.  Probably won't happen, but it is still a good direction to go.

 

I agree with you on many levels.  

 

But when it comes to spending hard earned dollars, I like to do my homework and make the smart purchase.  

 

When I advise others, I try to advise to them what I myself would do.

 

The "standard" motherboards are a sure thing.

 

If a person already has a motherboard and wants to use it for unRAID - I think that person should give it a go and see if they can get it to work.  If they are successful, they should share it with the forum.  But if a person is going to buy a motherboard specifically for this one purpose, why wouldn't they buy the sure thing?  A person may save a few dollars, but the "insurance" of knowing that the motherboard is well tested with each new release is worth a lot more than the $25 or even $50 savings (IMHO).

 

To encourage exploration and documentation of motherboards, I think we may need to rethink how we request folks report hardware compatibility.

 

The ability to boot off of the USB stick and have a compatible gigabit ethernet are just too basic.  Lots of problematic motherboard can do that, including the one in this thread.

 

The areas where motherboards "struggle" relate to ...

- the ability to check parity successfully;

- the ability to check parity successfully with larger numbers of drives;

- the ability to boot from the usb when the number of drives goes over 10 or so (requires ability to configure USB as a bootable removable media and not as a hard disk); and

- the ability to run a full boat of drives

 

Maybe we should be defining a standard like the following, and asking folks to post syslogs of their systems to demonstate these levels of compatibility.

 

1.  Set up an array which will boot off of a USB stick and calculate parity on a 3 drive (free license) system + parity check with zero errors.

2. Ability to fully populate array to the limit of the plus license (6 drives), calculate parity, check parity, copy at least 10G of data to each disk in the array over the network, run at least a week without rebooting, and then run a zero error parity check.

3. Ability to boot and define a 12 drive array + cache, calculate parity, check parity, copy at least 100G of data to each disk in the array over the network, run at leasat two weeks without rebooting, and then run a zero error parity check.

4. Ability to boot and define a 16 drive array + cache, calculate parity, check parity, copy at least 200G of data to each disk in the array over the network, run at least a month without rebooting, and then run a zero error parity check.

 

If a motherboard can demonstrate level 4 compatibility (or at least level 3 compatibility) I would feel more confident recommending it to others.  Right now I just have no way of knowing how far the motherboard has been tested.

My woes continue....  

 

This machine is acting a bit more flaky now. It crashed sometimes during the night. Now both drives are showing blue balls and in the syslog 'md' thinks that they are new disks. They are assigned correctly and the disk.cfg file looks fine. Is it OK to start the array like this or is there something better I can to do to green ball these disks?

 

Thanks.

Very odd. The super.dat file saves array state info and must have been deleted or corrupted. My advice if the data on your drives is importanrt to you is to not try to use unRaid on this motherboard. If you do proceed, just be very careful to not assign a data disk to the parity slot. It would be deadly to the data on that disk.

Thanks for the feedback. I learned another nugget.

 

I had a backup of the config directory, so I restored the super.dat file and that green-balled my disks.

 

I also removed the modprobe cpufreq-nforce2. Even though it was still running the performance governor, I became fairly suspicious of all things nforce2 related. I just added that recently, and prior to that I have not had any crashes or flash file corruptions at all.

 

I am going to lobby that the Hardware compatibility page makes a more obvious stance against nforce2 based mobos, or at least ones that also have SATA controllers built in.

The stock unRAID kernel does not have CPU frequency scaling support.

 

The cpufreq-nforce2 is an FSB changing hack.... I would stay away from it. 

I am going to lobby that the Hardware compatibility page makes a more obvious stance against nforce2 based mobos

 

Your wish is my comm...

 

Hardware Compatibility, Hardware Known to NOT Work

 

I should have added a note a long time ago, somehow never occurred to me.  Please critique, does it need more, or less, or clearer?

Have you got the new motherboard yet? It might be best to put this on hold until you have the new motherboard installed. No-one here wants to see you have data corruption problems and it seems your present hardware has something really wrong with it. Best to just stop and wait.

 

I would get the new motherboard up and at the least do an overnight memory test before using it. You could also run a boot disk of some sort and run a processor burn-in on it.

 

 

In that state I don't think the start button is available. Do you have the drives assigned to the right spots? If you have to press restore then before using start type this command.

mdcmd set invalidslot 99

This will tell unRAID the parity drive is good and start a parity check instead of a parity build. So, if all the drives are good a "Restore" and this command will take you to a parity check state.

 

 

The 740G chipset motherboards are not official but they're in fairly wide use with unRAID (because they are cheap and you can find board + processor combo deals every now and then for about $60) with no reported problems yet (cross our fingers ).

 

 

Rob - That looks good

 

Peter

 

 

Hardware Compatibility, Hardware Known to NOT Work

 

I should have added a note a long time ago, somehow never occurred to me.  Please critique, does it need more, or less, or clearer?

 

Yes, I think that states it very well. So many of the hurdles I've tried to clear have been because of this board and nothing else. Lots of stuff learned, but also a lot of time invested.

 

The stock unRAID kernel does not have CPU frequency scaling support.

 

The cpufreq-nforce2 is an FSB changing hack.... I would stay away from it. 

 

I know. Your kernel as well as the custom kernel I built had the scaling support in it. I knew it was a tweak to the FSB, but many folks had met with some success running that. The support for that has been in the kernel for several years now, but I think it was much more vetted on laptop based designs. In the end I just wanted to underpower and underclock the cpu, at least in idle conditions. I got something different however.... 

What are you expecting to run on this server?

 

If it's just the stock unRAID more or less then underclock in the bios if that's supported. unRAID requires so little CPU resources that most new CPU's you can buy will be lucky to be 25% utilized.

 

Peter

 

I had pretty modest goals for my unRAID. My number 1 desire was to have a safe, large and expandable NAS for media and some other static files (i.e. backup image offload). Maybe I will get torrent or nzbget working. The other thing was do to simple remote printer attach. You are correct that my fundamental needs are way under the performance levels of todays CPU's. Most likely I will play with BIOS underclocking on my new motherboard (if I even play with it at all), once things are up and stable. Cron based s2ram with WOL is probably a better way to save power, so that is a lower hanging fruit.

The stock unRAID kernel does not have CPU frequency scaling support.

 

The cpufreq-nforce2 is an FSB changing hack.... I would stay away from it. 

 

Paul -

 

As I read this warning from bubbaQ I was wondering if it was possible that THIS installed hack is what screwed you up.  If I understand FSB right, this hack might very well interfere with memory accesses - which was everyone's first thought when you reported the problem.  Memory testing would work fine because the hack was not in place.  

 

If this hack was not working right, and you ran a parity build, your parity would be all scrwed up.  And then if you ran a parity check while it was screwed up, it'd just get screwed up differently.  Then, when you loaded another version WITHOUT the hack, it would straighten out the parity, but you'd still get a ton of sync errors and you wouldn't know.  You'd have to run a parity check 2 times in a row on stock, unhacked version of unRAID to know for sure.

 

I'm not sure if this is it, but it seems to fit the facts pretty well.  Might be worth checking out.

 

(Just saw your latest post ...)

 

I had pretty modest goals for my unRAID. My number 1 desire was to have a safe, large and expandable NAS for media and some other static files (i.e. backup image offload). Maybe I will get torrent or nzbget working. The other thing was do to simple remote printer attach. You are correct that my fundamental needs are way under the performance levels of todays CPU's. Most likely I will play with BIOS underclocking on my new motherboard (if I even play with it at all), once things are up and stable. Cron based s2ram with WOL is probably a better way to save power, so that is a lower hanging fruit.

 

If your data is important to you, I would urge you do set up a test array so that you can do all your testing and experimenting there.  I try to run my production array as close to stock setting as possible (no overclocking, SPD memory settings, stock voltages, etc. etc.).   If nothing else, it means less variables to worry about if something goes wrong ...