electron286

From what I gather... I may be way off though... The mvsas driver code has not changed itself in quite a while... BUT with the kernel changes, (as with kernels for different variants of Linux), often libraries and other dependents do change, so even though the mvsas driver version number may remain the same, it gets new builds with the different kernels. Prior to 0.8.16, it looks like there was a lot of changes in code, I found at least 5 different -x revs for 0.8.15 (0.8.15-d as an example) So, from what I can tell, 0.8.16 may still have all the bugs identified to date, BUT they may mostly, (if not fully), be caused by changes and updates in the various linked libraries and dependencies... which will vary from build and flavor of the kernel in use. I am also a bit perplexed, as some of the links seem to specifically CHANGE the mvsas code, and yes do not seem to update the version to a different rev! So then how do you know which mvsas code you are running as compared to what has been altered? Sometimes things like that seem to get a bit out of hand with open source... Changes for the sake of attempting fixes... committing changes, etc...

Thanks for sharing the info. and link for the dskt.sh script! Very cool little tool! I would think © is the likely one... but I am used to bus limitations running mostly older hardware, so it may not be the case for you...

Your choice for a SAI/UPS looks like it might indeed be a good choice, depending on what you need it to do. I am not familier with the brand, there are so many units not sold everywhere in the world... Also a BIG thing to make sure of, is what output power connectors are on the SAI/UPS - Since you are in Europe, there are sometimes various plug configurations. Make sure what you order will work for you, and that you can get needed power cables easily. It seems the best option would be a SAI/UPS that has an IEC set of power outlets, so you can use a standard IEC to IEC power cord from the SAI/UPS to your computer. 1. It is line interactive, so with voltage fluctuations it will increase/decrease voltage WITHOUT switching to battery. This will allow the battery to still be at full charge for use when a power outage actually occurs. From my experiences, often power outages are often preceeded by other voltage variences, which with cheeper designs will run the battery down before a power outage. 2. Battery run time could be longer - Personnaly I try to aim at about 30 minutes of run time, or more... The bigger batteries do make the SAI/UPS cost more, and end up taking more room, and really make the unit heavy to move frequently... but it give more versatility, and as the batteries age, the run time drecreases also... effectivly making the unit usable for longer periods betwwen battery replacements. Longer runtime gives the chance of keeping everything on, and riding through a shorter power outage, instead of needing to shut down for short power outages... 3. I personnaly also like a higher capacity SAI/UPS... it gives me the ability to connect more in the future, should I want to. It also give a higher safety factor, so I do not need to worry as much about derating if the temperature is high and still run my load I would have connected to a smaller SAI/UPS... I might also look at: ( Schuko - outlets ) http://www.amazon.es/Salicru-SPS-700-ONE/dp/B00564ZNIO/ref=pd_cp_computers_0 http://www.amazon.es/Salicru-SPS-900-ONE/dp/B00564ZNVQ/ref=pd_cp_computers_1 ---- This is the one I would probably TRY because of price/features (plus the colour is really cool!)- BUT for the one I would really recommend and is like what I usually use see below under APC ---- They both seem to also be good units, but I think they have the same size battery possibly as the one you were looking at. These units also come with cables for data communications with the computer! (I have NO idea if it would properly talk with unRAID and shut down the computer though... - for that see APC below...) The various manufacturers always seem the rate run time differently, so I would expect likely about the same run time as the one you had been looking at... :-( But, the 700 VA and 900 VA units give more load head-room... :-) One thing I also like about these, is they specify sinewave output also! The one you refferenced, I did not see it stating if it is sinewave output or not... If you want to spend a little more... APC: This is the brand and series I usually buy... (but the versions for the USA market...) http://www.amazon.es/Apc-Smart-Ups-Sc-420Va-Conector/dp/B0006ZXLZA/ref=sr_1_187?s=computers&ie=UTF8&qid=1370009890&sr=1-187&keywords=UPS http://www.apc.com/resource/include/techspec_index.cfm?base_sku=SC420I ( IEC 320 C13 outlets ) - I think this is the same as the above link... I would buy a larger VA model though... This one costs MORE again, has the larger battery set, for longer run-times, plus is rated at higher VA for more loading, (multiple computers, etc...) and under higher temperatures after de-rating, will keep things running stably more easily... (this is the version I would recommend and is the closest to the SMALL ones I run...) http://www.amazon.es/Apc-Smart-Ups-Sc-620Va-Conector/dp/B00079VLM0/ref=sr_1_2?s=computers&ie=UTF8&qid=1370011726&sr=1-2&keywords=UPS+SC620 http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=SC620I&total_watts=200 This has also seemed to be a good brand... http://www.amazon.es/Eaton-Powerware-5115-500-05146549-5591/dp/B000L4CG0W/ref=sr_1_210?s=computers&ie=UTF8&qid=1370009923&sr=1-210&keywords=UPS

mvsas driver version 0.8.16 - has at least been around since 2011 Sep 28. seems that there are a few issues that seem to have occured at the 0.8.16 driver rev... this is possibly somewhat relevent info... ? http://comments.gmane.org/gmane.linux.scsi/79430 (same informatioon is replicated on multiple mirrors...) (also other reported issues, also seemingly widespread at same rev - needing the driver early loading fix...) possibly see also : https://bugzilla.kernel.org/show_bug.cgi?id=51881 then there was this: https://patchwork.kernel.org/patch/1984091/ and this: https://patchwork.kernel.org/patch/1989901/ and from Marvell... not sure if most current... https://git.ipxe.org/mirror/scst/.git/blob_plain?f=mvsas_tgt/README

Any pre-cleared drives, or any drives with data from unRAID previously, should work fine on the newly flashed controller card. No re-formatting, or re-pre-clearing again should be needed. Just a matter of properly mapping existing data drives in pre 5RC unRAID installs, and should as already mentioned by Ford Prefect, re-mapping will be automatic with current 5RC versions. If something asks to be formatted, that should have data on it, or appears to have not been pre-cleared, even after it had been... Something is likely wrong, and you should ask about it here before proceeding.

Memory standards do change, and some terms have migrated, to some extent, from one definition to another over the years... Compatibility, match compatibility codes on CPUs and mother-boards, follow manufacturer recommendations for CPU, motherboard, and memory match-ups... If marked as 'supports' it may also suggest in some instances that other configurations are NOT supported... Bottom line, make sure you are using the documentation that was (is) current at the time the system components were produced, and or updated... (this will sometimes also equate to a mother board claiming compatibility with a given memory size, and or standard, that then later to revisions in memory, may not be usable...) As a result, the information to follow next, may not be 100% correct, now, in the past, or in the future... Just because a memory configuration "may" be valid electrically, it does not also mean that it is now, or ever will be actually made available on the market, or at an affordable price point if made available... Now the disclaimer and fear factors have been issued... 1 - Un-buffered memory modules - The basic "desktop" memory standard, cheap and easy to find. NO extra special features or functionality. SHOULD work in all systems designed for Un-buffered memory, (even boards designed for ECC Un-buffered - but BIOS settings may NEED to be set to disable ECC, or memory errors may be EXPECTED) 2 - Un-buffered ECC memory modules - Same technology as #1 above - ADD extra bits for ECC for single bit error detection and correction and multi-bit error detection. For ECC BOTH the mother-board needs to be designed for it, it needs to be implemented AND ENABLED in BIOS, AND the CPU NEEDS to support it, (in newer generation hardware), (or in the case of older hardware, active support needs to be implemented in hardware memory controllers, and is transparent to the CPU) 3 - Registered memory modules - (sometimes referred to as buffered modules) - (buffered and registered are similar and while older memory standards were simply buffered, the newer registered memories use a slightly different approach to accomplish the same thing) - Essentially buffers the memory from the memory controller on the mother board, providing a more stable electrical interface for data integrity. This creates a slight additional delay in data transfer, so memory cycles are a little longer. (but if faster memory is used, the overall delay may be non-existent). - MUST be used on a motherboard designed to use REGISTERED (or buffered on older systems), (even boards designed for ECC Registered - but BIOS settings may NEED to be set to disable ECC, or memory errors may be EXPECTED) 4 - Registered ECC memory modules - This class incorporates BOTH add-on technology options. (see #2 and #3 above) - Same board and CPU/hardware requirements as #2 for ECC use, For ECC BOTH the mother-board needs to be designed for it, it needs to be implemented AND ENABLED in BIOS, AND the CPU NEEDS to support it, (in newer generation hardware), (or in the case of older hardware, active support needs to be implemented in hardware memory controllers, and is transparent to the CPU) - Same electrical requirements as #3 above for electrical interface, - MUST be used on a motherboard designed to use REGISTERED (or buffered on older systems). Summary - Un-buffered should only be used with un-buffered - Always match memory to mother board. Registered should only be used with registered - Always match memory to mother board. ECC use requires full support, Mother board, memory controller, BIOS, and/(or) CPU (depending on age of hardware). ECC memory modules SHOULD work on hardware that does not have support for ECC functionality, (but no guarantees there...) The extra bits, would be wasted and a waste of the extra money to buy them for such a system... Special notes: - SOME motherboards have multiple memory slots to support different memory technologies and standards, USUALLY only ONE type should ever be used at a time on these boards, such as ONLY registered, or ONLY un-buffered - or ONLY DDR-2, or ONLY DDR-3... etc.. (for REALLY REALLY OLD examples... ONLY SIP or SIMM, ONLY DIP or SIP, ONLY 16-pin DIP or 24-pin DIP...) - There is another type NOT mentioned above - FULLY BUFFERED memory modules - These are NOT electrically compatible with anything mentioned above and SHOULD be physically keyed differently to prevent insertion into incompatible motherboards. Allows higher density memory configurations, at reduced performance levels... (I would suggest to AVOID these completely)

Found some information on the driver being loaded for the 2760A... The mvsas driver version 0.8.16, has been used under the following environments WITH THE 2760A: Ubuntu 12.04 - using multiple file systems, including ZFS - after changing order of driver loading to be earlier... Ubuntu kernels 3.2, 3.5, and mainline build 3.6.11, and 3.5.0-21-generic #32 - after forcing mvsas in to the initramfs to get it to load earlier. - that helped a great deal but the root cause of the issues seems to be that the first series of commands sent to the controller are timing out. Subsequent commands work fine, and the controller behaves properly after that. It sounds to me like the main thing to look for might be initial commands issued after unRAID booting in your instance. Since this seems to be a common known issue (at least under Ubuntu) using that driver version, it would be good to just make sure if the problem is also there under Slackware (unRAID) or not. But also people are using the 2760A with no problems after initial startup under Ubuntu. I would hope that, nor would I be surprised if, things might actually work a little better with unRAID using this driver than has been seen in the Ubuntu world.

I have not used ESXi, but, from what you plan to run as VMs, I would think that 8GB of RAM should work, but will likely not be as much as you will want to use. Depending on how much you will be wanting the Windows VM to do, you may really need extra memory there, if you are going to be running 64-bit Win 7 that is. If just using 32-bit Win 7, you may actually be very happy with the 8 GB amount of RAM. The other VMs should be fairly memory efficient. Bottom line, 8GB should be good for testing, and then deciding later if you want more.

hilljd00, Is that what you were going to run Unraid virtualized under ESXi? If that is the situation, that looks like it may be the problem...

I would really like to know how good the trayless one is... so yes I would like to see a review! :-)

Not sure if it is still there, but look at this for a source where you are for the M1015 http://www.sulit.com.ph/index.php/classifieds+directory/q/IBM+ServeRaid+M1015?x=2 If that one is no longer available, look here for the nearest athorized dealer: http://shopap.lenovo.com/SEUILibrary/controller/e/phweb/LenovoPortal/en_%7BCOUNTRY%7D/special-offers.workflow:ShowPromo?LandingPage=/All/AP/Partner/Bplocator All the dealers there, SHOULD be able to special order one for you.

:-) SInce I now have one, I can't help but smile when people have the same reaction I had when I turned mine on... LOL... I wish there was a word louder than loud... I personnaly have never heard a server in a server farm as loud as this one. But is is a great unit, and is very well built! And on the secondhand market, you just can't beat the price! I also had looked at the power supply mod, to a standard unit, but I really like the redundant power supplies... :-(

Another option if your motherboard is not too large, would be to make a small adapter plate with thin sheet metal, and mount the drive to it using the bottom mounting holes on the drive. Then mount the adapter plate with the drive attached to the available motherboard mounting posts. While I have NOT done this with Norco cases, I have done both methods of mounting on other cases to add more hard drives than were ever intended to work inside various tower cases. With a little extra care and sometimes adding fans, it always worked out nicely, even though it looked a bit odd... With all the room in the 4224 it should work very well, including cooling.

I have the Norco 4116, and in looking at pictures of both the 4116 and the 4224, they look like the same chassis behind the drive bays. If I was going to mount an internal drive, and if my power supply was not too long... I would place it mounted standing on a side using the slotted raised mounts intended for redundant power supply frames. I would monitor the temp a bit during a parity check to make sure it had enough air flow, but it looks like the cooling should be good in that location too. That location should also make it easy for screws to not be in the way on the bottom of the case. :-)

VERY COOL!!!! It does look like multiple CPU power down options DO work now in 5RC, and they ARE NOT in 4.5.3, which is what my main unRAID builds are on... also I just noticed the lsmod command, which lists which modules are loaded... Looks like another good reason to make the switch to 5

It sounds like you should have a decent capability already. Yes I agree, any improvement by just switching components and/or cables around would be worth while. It is always nice to get the very most out of an existing hardware configuration. It never hurts to try a different configuration to see the performance. I do that quite a bit myself. Let us know how the testing ends up, it would be nice to see what differences there might be with the parity drive on the MB port.

The speeds you are getting look pretty good to me, depending on your hardware. You might find out after testing, that to speed things up as much as you would like, you may need to update your CPU and/or motherboard... and/or make some other changes.

I updated my post after you answered.. Cooling aside, (see my updated post) I think I would do some tests to see if it was worth moving the drive. You could temporarily hook your parity drive to one of the motherboard SATA ports, and start a non-correcting parity check and see what speed it runs at and check it about each 5 minutes for 30 minutes. If you do the same test with the parity drive in the tray through the SA backplane, then you will see how much it will improve performance, or not...

If you are NOT using a SAS to SAS multi-drive cable from your controllers to your back-planes, it would be easy to just move a SATA cable from your add-on controllers down to your mother-board. But, if you are using a newer card that has the SAS multi drive connector, you also likely have high enough transfer rates on that card that moving the drive to your mother board connector may make little difference, if also on a somewhat newer hardware MB CPU combination. My biggest concern would be getting proper airflow and cooling on the parity drive if it were to be relocated inside the case. Just to make sure there is not a misunderstanding, the SAS back-plane is NOT a limiting factor by the way. It is not like a port multiplier like some people seem to think.

I have wondered that for a long time myself... From what I remember, AMD power saving features were possible in the linux kernals before Intel features. But from what I have learned.. long past and possibly way outdated now... There was no automatic implementation of power saving modes in Linux, and it needed to be done at the application level. :-( I could be wrong, but that was my understanding then, and lots may be different now.

This looks like a good thread for a question... I have a RPC-4116, with the SATA backplanes, not SAS. Has anyone else got one of the NORCO racks with SATA backplanes? If so, does anyone else have the situation where the drive trays do not match up with the actual LEDs on the backplane? In my case; 1. The green drive power LED shows through the lower light pipe to the hard drive activity front bay indicator. 2. The blue drive activity LED does not show at all on the front! It is lined up with the masked out middle light pipe. 3. The upper light pipe which lines up with the drive power front bay indicator, has NO LED behind it on the backplane. Does this mean there is some version number of bays and/or SATA backplanes that are correct, and match up? Did I just get shipped a bogus combination of engineering change rev parts that do not match up?

When I fisrt started using unRAID, I did not even think about (nor had read about...) doing periodic parity checks. 'out of the box' unRAID, as garycase said, does not initiate parity checks, they only occur when you ask one to run. There are some VERY good reasons to run them on a periodic basis, and monthly seems to be a good period. unMENU does make it very easy to set the monthly parity check. This will force a full read of all the surface of your drives! This gives the drives internal SMART monitoring circuits to check and re-allocate if needed, and areas on the disc that might be deteriorating. This process is invisible to the user, if done often enough to catch it before loss of data on a drive occurs. I had one netbook drive, as an example, that did not have very good media, and would not retain data at some locations for more than a few months or so. Since I never did a full surface read, by the time I read a failing area of the disk, data was lost and files corrupted. Even the restore partition had areas that had failed!@@@ "luckily" I am a bit paranoid, and had made multiple disc images of the hard drive when I bought the netbook, even before I loaded any software on it and started to use it... So after a few re-stores, I finally gave up and replaced the hard drive, with a larger one... :-) all is good now. I just need to find an easy way to check my drives on my windows computers, that works as easy as the monthly parity check I let my unRAID systems do on their own...

Not at beta now, at RC level... While it may a bit unsettling perhaps to go with some software that is "not final released' version. The current 5 RC is FAR past beta stages. RC is used to identify a release as considered ready for release, Release Candidate, and if there are not any significant reasons to change it prior to final release, then will become the released version, with no changes other than the name... All the RC releases have been very good, with minor (mostly) changes made alone the way. It is looking like we may possibly be at the last needed change... there are always things that could be changed, but it seems there are not any major concerns now. As always there are always features that people may like to see, but that would eventually be rolled into another updated version, if accepted as valuable. This comes down to a matter of preference, and comfort level... For me, I like to add parity when I create an unRAID array, without it, you have unprotected data. So why use unRAID, if it is acceptable to have unprotected data, even for a short time... Other people do not add parity till they have copied data over to an array on a new build. It allows for faster data transfers at full disc speeds, instead of limiting based on parity creation speeds... Then add the parity later to build the parity drive based on the array data. You may want to even consider a hybrid approach. Determine which data is most important to be transferred, and copy it LAST to the array. a. First transferring non-important files WITHOUT a parity drive. b. Then add the parity drive, build the parity from the array. c. Then with parity active, transfer the remaining more valuable data, including data from old drives that will then be cleared for use in the unRAID array where another backup may not then be available... As a rule, I always put my parity on the FASTEST port with the most bandwidth available, especially if it is on a dedicated bus! Not so important in your case, but VERY noticeable on older hardware builds with multiple interfaces and drives... After all the parity drive gets lots of work at times, so I also like to try to give it a chance to keep up with everything else and at least reduce one bottleneck as much as possible... There are no silly questions, when trying to learn something. :-) I would be VERY happy to see those speeds! But older hardware like I normally use will never see that good! Not bad speeds at all! :-) Also, a big thing to realize, as garycase mentioned, 6Gbps and 3Gbps refers to the INTERFACE speed on the drive, which might be able to almost be reached with cached data, but is much higher than the actual sustainable data rate in physical platter drives. This is where enterprise class server grade 10,000 RPM drives will really start to show off their power, much higher sustained data rates compared to green low power drives. (in case you were not aware, the REDs are essentially green performance drives, built with better physical parts used in the enterprise class of drives, like bearings etc.. - - unless that has changed again since the release of the RED product line...)

Pauven and garycase... When periodically checking your parity check speed, where are you looking? On the main unRAID console web page, or a plug-in like unMENU? Are you just manually re-freshing the page when you want to look at it? The reason I am asking is that most of my unRAID configurations are running on MUCH less capable hardware, so it is noticable that when I refresh a web page numerous times, that the parity check slows down and expected time to completion is extended... to be expected with slower, older hardware, that is maxed out with a parity check... So with a nice new, not pushed to the limits, system running parity checks, do those numbers even change with multiple web page refreshes? I was thinking while watching your test results... it might be really nice to write a script to capture the data at fixed intervals, such as 15 minutes, or 30 minutes, and place them in a CSV file to later make charts, and be available for further analysis steps... perhaps overkill, but it would make it very nice for a repeatable test between hardware tests and changes... :-) Maybe a new thread there too! :-)

I was also thinking as I wrote, that 2 - 3.5% efficiency by itself, is probably not worth a move from 120 VAC to 240 VAC operation. In a large data center there are many other advantages too. The most obvious is the size of scale and multiplied savings. If you only saved 1% of a $10,000 electric bill per month, it would be very nice! BUT, you may get some additional advantages also like are seen in data centers, depending on how much equipment you are running... Other factors to consider... IN a data center environment, you do not have random people, unfamiliar with, or unaware of the 'commercial' standard wiring of 240 VAC to the server equipment. So the chances of someone accidentally hooking up the wrong voltage to a 120 VAC piece of equipment is less likely. There are a number of server class power supplies, from multiple vendors, that actually are rated at HIGHER wattage output when used with 240 VAC rather than 120 VAC power. (This is due to the higher DC bus voltages attained in those designs, and the way it is frequency/time duration converted to the lower output DC voltages.) Running a UPS with 240 VAC, yes very common in data centers, also introduces another level savings! Many, UPSes also see about a 1.5-2.5% increase in overall efficiency compared to a similar 120 VAC speced model, (or same with lower 120 VAC voltage order specification.) Twice as much equipment can be run on the SAME size of wire! With a standard 120 VAC 20 AMP circuit, provided by a single run of 12 AWG sized wire, you can provide 1440 WATTS of power. If you have a 240 VAC 20 AMP circuit, it would also use the same single run of 12 AWG sized wire, and would be able to provide 2880 WATTS of power! In a residential service, this would be a change in the breakers from a single pole, to a little more costly double pole breaker. If sourcing higher quality spec grade outlets, the price is about the same for NEMA 5-20 (120 VAC) and 6-20 (240 VAC) Depending on the power design in a data center, they could also save a little more by also using a single pole breaker for the 240 VAC power, not a lot of savings, but on a large scale project, it would add up to initial installation savings. So, if you have enough computer equipment running, to make it more close to a data center wiring model, your savings may very well be worth it, both in initial installation savings to provide power to a large number of computer resources, (copper wire savings - reduced circuit count - not to mention reduced heat loss in wiring if running near ratings...) Potential efficiency savings on a properly specified 240 VAC UPS, plus additional efficiency savings on the computer power supplies. For me, I run a individual branch circuit to a single dedicated outlet, in EACH room, where I expect i might EVER want to have a computer, I have just run 120 VAC circuits however so far, since I want it to be east for anyone that may use it in the future. I also run all of the computer circuits from a dedicated power sub-panel. That way I can easily connect to a large centralized UPS and/or generator set-up should I ever decide to... (after all, who needs lights in a power outage, when you can have a computer!) In an area I expect to be data-centric, I run multiple circuits, and try to plan for future expansion possibilities too, (such as with a finished basement planned, run over-sized conduit to such expected areas, even though not usually used in residential, to allow for additional added circuits in the future...) This usually means empty conduit for now, since I already ran Romex and thought about future needs later... It is also nice to have smaller 1/2" or 3/4" conduits (PVC is fine) run to home run termination points for network wiring, etc. This way you can upgrade easily from old RG-62 (ARCNET), to RG-58 (ETHERNET 10Base-2), to CAT3, ETHERNET 10Base-T, to CAT5e/CAT6 - ETHERNET 100Base-T/1000Base-T, to fibre?... (no not yet...) While still related to power efficiencies this should probably move to a new topic if more comments are needed... ;-)