electron286

Not good. :-( Not sure about these people, but there are some groups that do it, not to attack, but to let people know that they need to increase the security on a web site to prevent it from being exploited. Sadly, even if this group is in the later marginally noble group... Once tagged, or 'defaced' the site is marked as vulnerable, and thus, posted that it can be hacked. REALLY NOT GOOD... :-( :-(

TAMS has LOTS more of the 24 bay super-micro servers in! It sounds like it is the largest lot they have ever gotten! These are from a VERY LARGE data center upgrade! They have enough to fill all back-order list requests, plus HUNDREDS MORE! They are going through them as fast as they can, pallet by pallet, so more variations may show up in the lot... but so far they seem to all be AMD based. I just picked mine up yesterday and am just starting to look at my new toy! What I have is the newer H8DME-2 version 2.01 mother-board, w/ 8GB of RAM, and 3 each of the SAT2-MV8 boards! What I have been told so far... (of the 24-bay super-micro server batch) All the servers have the SuperMicro SC846 4U rack mount case! All the available servers have ALL the drive caddies! All have the dual-power supply redundant configuration hot-swap capable. SO far they all seem to be Ablecom PWS-902--IR 900 watt models! All have 8 GB of RAM installed (for the ONE processor installed) - (mine was in 4 each 2GB sticks) All have 3 each of the SAT2-MV8 PCI-X controllers! All have one IPMI card - Kira-100 (if you want ot use it...) The difference is the CPU... the Dual-core equipped (AMD Opteron 2212 HE @ 2Ghz) server is selling for about $50 less than the Quad-core (AMD Opteron 2346 HE @ 1.8Ghz) server. (I just went with the cheaper one.) I had "heard" that the fans were loud, that is an understatement! I really think it might might be possible for one of these servers to move with the air flow if not weighted down, filled with drives, or mounted in a rack... (ok, slight exaggeration, but it does make me keep looking to make sure it has not moved yet - and you may really want to use ear-plugs before plugging it in!) (getting in the BIOS you can change the fan control from OFF=full speed, to Server=slower, or Workstation=slowest, but still not quiet) I am not sure, since I have not lots with AMD based boards, but I may have an issue with my CPU fan (4-pin fan and socket). It is only bumping a little, sits still, then bumps about 30 degrees and stops again... I think it may be how the temperature settings are in the BIOS or just the way the CPU interacts with the PWM fan. The heat-sink is cool, so it may not be trying to run the fan much yet. I did verify the fan works plugged into another (3-pin) socket. One problem I did notice, I HAVE NO SCREWS FOR THE DRIVE BAYS to mount drives! I would think that TAMS might have them, unless the drives were already removed before they received the servers. So, if you are going to get one, make sure you ask about screws for the drive bays also! (it looks like the screws should be about the same as the ones used in the Norco server chassis cases. - at least mine work.) Links: for BIOS update for SAT2-MV8 - ftp://ftp.supermicro.com/Firmware/AOC-SAT2-MV8/ (mine were already current) for MB manual - ftp://ftp.supermicro.com/CDR-A+NVDA2_1.21_for_A+_nVidia_MCP55_platform/MANUALS/H8DM8(E)-2_1.1a.pdf Drive Bay Screws: http://www.superbiiz.com/detail.php?name=CA-MCP45ON http://www.provantage.com/supermicro-mcp-410-00005-0n~4SUP91J0.htm http://www.amazon.com/Supermicro-MCP-410-00005-0N-Screw-100PCS-Hotswap/dp/B004P4ZGRO http://www.pcrush.com/product/Fasteners/718336/Supermicro-MCP-410-00005-0N-Screw Quieter fans... (you may want to buy 5 of these!) This case uses 80mm fans, not 60mm like the ones listed earlier in this thread... http://www.newegg.com/Product/Product.aspx?Item=N82E16811999616 NOTE: These fans are thinner than the original fans. It does not seem to be a problem with the internal 3 fans, but for the rear two fans, a small piece of tape or something needs to be placed on top of the fan shroud for proper air flow... These fans are nice in that they change speeds with measured temperatures, staying VERY quite at low temperatures while speeding up if needed, but still at full speed MUCH quieter than the original (jet engines)...

Just to make sure we are talking the same units... Mb = MegaBit MB = MegaByte Mbs = MegaBit per Second MBs = MegaByte per Second Are we really talking about MegaBit rates here? I have NEVER gotten any transfers that slow even with my 100Mb equipment. With 100Mb, I usually see reads to and from anywhere usually above 90%, about 90+ MegaBIT/sec (Mbs), or about 11+ MegaBYTE/sec (MBs) If you really are only seeing your numbers and the units are mega bits per second, there is a real problem on all the links of some kind. If however your numbers are really mega BYTEs per second, they are not great, but I have seen other people with similar numbers, From my tests on various hardware; with Gb, assuming the network switch(es), cables, and NICs are not problems, reads to and from anywhere on the network should be at or above 30%, about 300+ MegaBIT/sec (Mbs), or about 36+ MegaBYTE/sec (MBs) - based on tests with older 1st generation of Intel P4 WITH hyper-threading support running at 3.2 Ghz. (same era 40Gb harddrives maxtor/WD) with only between 256-384 MB RAM. running XP-PRO SP2 With WRITES to a not too current unRAID (4.5.3) with older, but not ancient AMD Athlon 64 X2 2300 with older PCI Promise Fastrack S150 TX4, and older SuperMicro SAT2-MV8 just running on the PCI bus interface. Speeds drop to about 27%, about 270 MegaBIT/sec (Mbs), or about 32 MegaBYTE/sec (MBs) using the same base computers as listed above. This is running PARITY with an array of 5 WD 1.5TB EADS data drives on the add-on cards on PCI, and 1 WD 2TB black FAEX running parity from the mother-board SATA. All speeds go up with more capable/current test computers above the old 1st gen Hyper-threaded P4 series testing with the same unRAID configuration. To a max with my tests to date, (limited by my test hard drives in the other systems on network reads) that were file COPIES from a tested network drive source to local hard drives, (the write to the local drives were the bottle-necks yeilding a 99% disk utilization) need to test with newer/faster hard drives... Reads 45% (local disk maxed out) from unRAID to local drive (Maxtor 40GB), 450 MegaBIT/sec (Mbs), or about 55 MegaBYTE/sec (MBs). WITHOUT Parity enabled, to test max speeds, writes with this limited hardware actually were FASTER TO unRAID than the reads were, due to the write speed being so much slower than the read on the test machines. Writes (copy of files from local hard drive) to unRAID (same as above) 60%, 600 MegaBIT/sec (Mbs), or about 73 MegaBYTE/sec (MBs). Adding parity again brought the write speeds down to 29%, 290 MegaBIT/sec (Mbs), or about 34 MegaBYTE/sec. These higher tests are still on rather old hardware for the test machines, newer P4 2.8Ghz - socket 755 32-bit (just before the 64-bit enabled chips) with 512 MB of RAM running Windows 8 Pro, yes it does work with that little RAM... Anything slower than these numbers with similar, or better hardware would likely suggest other bottlenecks, (again assuming that the NICS, cables and any network switches have been ruled out as being slow...) such as CPU, memory, hard drive, mother-board issues... or even extra processes running slowing down transfers and/or eating up of CPU clock cycles. (SOME software updates, such as Windows service packs, hot-fixes, etc., as well as SOME anti-virus/anti-malware software updates, have also been seen to DRASTICALLY slow down computer processes and data transfer speeds.) Long reply, but hopefully it can be helpful... All my tests have generally concentrated on older hardware to ensure minimum configurations are usable for my purposes. Then I just enjoy how well things work with even newer configurations... A couple last thoughts... a cross-over cable directly between two computers eliminating any other devices between the two, might also be helpful in eliminating other network devices as the problem, such as a bad switch. Software that runs all the time, such as anti-virus and ant-malware, may be disabled with such tests to further identify their effects on transfer speeds. Looking at CPU usage and tasks can also help to identify if there are other processes that are potentially slowing things down during transfers also.

I would say that; VERY frequent parity checks = Safer Data - Hidden data recovery (SMART LEVEL) - fewer parity check errors reported, if any. Rare or NO parity checks = At risk Data - Not enough use for SMART LEVEL repair - Highest amount of parity errors likely reported. I feel that the best setting would be somewhere in-between the two. I feel the suggested 30-day interval is good, it is more frequent than should be needed, but spread out enough that a failing drive should actually be noticed, instead of fixed frequently on the fly... Yes, it comes down to comfort level... So, based on what your definition of drive failure is, a more frequent, (daily) parity check could have less data loss, and seem to be a good drive... while one that is not checked as often may get replaced sooner, even though it may actually be more healthy than the drive still in use in the daily parity check scenario. I have seen with some drive faults, that running a parity check too frequently, will repair (heal/relocate data) without the use or unRAID ever knowing about it. (but that was the whole idea anyway...) So no data lost, and with some drive firmware the re-allocated sector count information does not show either! Some drives do NOT start to even increment/decrement allocation counters untill the number of spare sectors/clusters reaches some pre-determined level... typically in such instances the number that is equal or near the counter value. Many newer drives have FAR more spare space available than would be expected from looking at the SMART values. So untill the drive degrades to those numbers, (which from most manufactures were set as vendor default counts years ago before we had LARGE drives), the numbers will not change. If you look at SMART values frequently, you may see a pending sector re-allocation event, then later see it is back to ZERO, with no change in the allocated event table... If you wait longer between the parity checks, it is more likely that you may see the drive faults as they increase in severity, so you can tell that the drive actually is in need of some attention, even if it is normal SMART self-heeling... The point is that at this point you may want to increase the frequency again of a parity check, to keep the data integrity higher, and allow SMART to handle things at the drive level. If there is a true reliability issue with a drive, it would be better to find out sooner, instead of later. That way the drive may still be under warranty and more data may not yet be on the drive... Until I started using unRAID, ALL my hard drives were always set to ALWAYS spin, I never would shut down a drive if the computer was on, and I would seldom shut down a computer either. I have seen more cases of drive failures not coming back after a power down than anything else, (and fan failures for that matter also) due to bearing failure, but that has been after MANY YEARS of non-stop use. So it is all a matter of compromises, whaich type of failure can you tolerate, and where the best average compromise may be for a given application.

I agree, it does sound a little unexpected that it would not work with the Intel Core series of chips... I am not sure, but I think it may be that the chipset and/or BIOS on your mother-board may actually be the problem. There were some design concerns on the Core series involving compatibility, but I would not expect that to be the problem here. I think it more likely that your BIOS and or chipset does not "fully" support the Core CPU you have. I suspect that some of the CPU features may not be available for use with the combination of components you have. A search for what CPUs are supported in the Slackware kernal may be in order... I bet you have already looked for the most recent BIOS, but you may want to take another look to see if you can update the BIOS, it may help. I have succesfully booted unRAID on older (if I remember release dates correctly) PIII CPUs (with the aid of a CD based boot manager - passing the boot sequence a USB FLASH drive) and not encountered any other issues other than finding usable drive interface controllers, since my OLD SCSI controllers were not supported.

I see your NIC in your computer is identified as being from Asustek Computer Inc. Not sure if it is on the MB or an add-on card of course. It looks like Asus usually uses Realtek gb chip sets. I have a large pile of realtek NIC cards, and mother-boards with realtek gb lan chips that will no longer function at gb speeds. They all worked well, at first, but as they age they all began to fail and deteriorate. I always compare files after copying over my network, and when the first one started to fail it passed corrupted files from one computer to another. As it got worse, more files would be corrupted. and speeds continually decreased, till finally it would only connect at 100 mb speed, and no longer connects to establish a 1 gb link. This has been the same path of symptoms I have now seen many, many more times... :-( I have also verified the same connection problems with the aged LAN chips on multiple gb switches and routers from numerous vendors. It is the Realtek chips, or surrounding components. (in my bad boards.) It is, in my opinion, that if you do have a realtek based gb LAN NIC, that it too may have now deteriorated to the point it is no longer usable. I do also have an early 16 port Netgear gb switch, that also started to fail port by port... and is also now unusable... So you may also have a problem with your router, but not as likely as a Realtek chip failure in your computer. It is also, as already pointed out, a possiblity of a bad cable, or even dirty plugs! Though again since you have a link, and are able to move data, very much less likely than the other possiblities. The only real exception here would be a cable that may have sustained some physical damage that has compromised the insulation integrity, that should be easy to see as damaged cable, sharp pinches, etc... From my tests to date, right now I would ONLY recommend (in order of preference) INTEL or MARVEL gb chipsets for LAN/NIC use. The Intel have better performance from my tests, (regardless of specific part number tested, though the more expensive ones are a little better...) Followed quite closely by the Marvell chips. Both seem to so far NOT have failed in ANY of my long-term tests, unlike the Realtek parts. I would also like to state that of the switches I have tested, only the early version of the Netgear gb switch I have tested has failed, all the other Netgear tests have yet to yield any failures. So I would still feel good in recommending Netgear switches and routers. (I would NOT suggest smaller, lesser known brand names for gb switches and routers however... had many failure tests there already) Other gb switch/router brands I have yet to see failures in my tests... that I also would recommend are Linksys, Cisco, Buffalo, Network Extreme, and D-Link. Of course even if you do have a bad NIC in a computer, it may NOT be your unRAID computer, but in another computer being used for the data transfer link... So depending on how many computers you have in your network, you may want to also try seeing how fast your transfer speeds are with a specific set of test files, from various computer to computer combinations, as well as checking for corrupted file transfers after a file copy from computer to computer... Intel NICs are readily available on-line in both PCI and the newer PCI express configurations. Some better local computer stores may also carry them, but usually they are hard to find locally, because they cost a little more, and most people would have a hard time seeing a reason to pay more for a card that does the same thing... add a LAN port, to a computer.

BTRfs or ZFS would be great for a cache drive, especially if it is also being used, as many people are doing, as an application drive! Adding a new protected array for the cache drive functionality would be a very good use of additional resources made available with the 64-bit hardware now available. If you also add the possibility of multiple parity drives, it makes 64-bit even MORE attractive! Yes these could also be built upon a 32-bit platform, but with many features run together, limitations will be seen much sooner with memory limits, and even code execution. So yes, I would make a switch to 64-bit, (well make another build) with such added features (priority for me would be the multiple drive parity option). There just is not enough horse-power nor resource capability on my 32-bit hardware to properly use such features.

ok, IF you can determine which bus each controller is on and which port of each controller the drives are on from the information as seen by the computer this may work for you... WITH THE DRIVES MOUNTED AND ARRAY ON-LINE... in 4.5.x (and probably other 4.x versions): simply go to the DEVICES tab on the unRAID web GUI interface... under Disk devices - the drives in the array (including the cache drive in this instance) will be listed in array order. For each drive you will see; 1. The PCI bus assignment - each controller will have its own address assignment. This MAY change with hardware changes, and BIOS hardware mapping... 2. The SCSI logical address - each drive will be connected to its own port on a controller. This SHOULD remain the same as long as a drive cable is always on the same port. 3. Host number and sd_ assignment - This is assigned on boot by the kernel. This one changes the most and is basically dynamically allocated. 4. Drive model and serial number as reported by the drive... This does not seem to be available on 5.x, (at least I can not find the equivalent in 5RC8a) You should be able to find the information by digging through the system log however... Yes, I have found this information very useful when testing various controllers and checking for performance and compatibility and stability. just makes it a little quicker to see some things when there are questions...

You can look at the system log, and read through it to determine which drive is on which controller and port... but it really much faster and easier to just open the computer and trace the cables. Also even if you know the logical address of the port on a controller, the port numbers do not always match what is printed on the PCB... Even after opening the computer, you may also still need to remove the hard drives to see the Serial number of each drive to figure out which one is which, unless you have already put a quick identification mark on each drive like was suggested with the last four digits of the S./N on each drive.

You are correct on all points... But there does not need to be, and seldom is there, logic in anything such as like, love or hate... I really liked the old button that was removed, as it really should have been, not because I have ever used it much, nor because I dislike a command line entry to replace it. I just use it for myself, and am aware of what it will do. When I need that functionality, I would rather just use it from the GUI as it was in the older versions. That is the real reason keeping me on my older version... I do like to test new hardware, (and old) for various new applications and acid test them prior to rolling them into a full time position... The old "restore" button does save me a little time when I need to use it. (also the bug, should it show up... will also let me know I need to look more closely at my hardware configurations to make sure there are no issues there that will compromise performance should I decide to keep a specific hardware combination for full time use. If all passes my initial tests, I am NOT averse to putting a newer version of unRAID on it for further testing and use... I have been very pleased with unRAID, and feel I know what to expect if there are problems with hardware under the version I am normally using... No I do not have problems much except for when testing known marginal hardware. Then I have found that newer versions of unRAID may actually run with no problems, even though the hardware is not what I would want to trust... In this way thee older version, though not as stable perhaps, helps me to identify potential problem hardware earlier in my testing phases... I do not need the additional logging information, for my purposes, (though it is nice for normal use especially if there are problems... I also do not need the additional safeguards for format operations, though fully a welcome update... I never use mc. it remindes me too much of the software it did a good job of copying, which I never really liked much... I prefer command prompts and writing scripts for my file copy, move, and compare operations. I do also agree with your comment about user confusion when faced with too many versions to pick from. I just like full archives, in this case perhaps just even making them available on another "older versions" page might be a good thought. The new page could be accessed from a smaller, not as attention grabbing, link on the normal download page where the only normally displayed versions are the ones that are current, (up to a cut off-point) like the ones that are now always available on the download page.

Sorry for this reply, a bit of a response to responses to earlier somewhat ranting type of post... First, I was only trying to explain, (very poorly perhaps), why I like to keep my old stuff running, possibly with new purposes or hardware or software added... I don't understand why you suggest the need to offer both 4.7 and 5.0 32-bit? 5.0 in its current 32-bit version has not removed support for any hardware that works in 4.7. In fact as hard drives get larger I think it's important to get as many people as possible off of it since it does not support 3TB and larger hard drives. Well, Yes 5 works well, and does a great job. I have had NO concerns with it to date yet. I just DO NOT LIKE the newer look and personally LOVE the older 4.5.3 so much more than the newer 4.7 even that I use it on most of my unRAID machines... even though there are REAL concerns with 4.5.3, that were addressed in 4.5.4, I do not like the change for MY use. I would of course NEVER recommend anything but 5.0 and newer for anyone else to use for a new server. But some times people do have specific likes or dislikes... ( call me odd... my kids do...) **************** I was a bit incoherent I guess... :-( I only mentioned the XT because it had been mentioed by many people in the thread. I thought it sad that the earlier IBM PC (and for that matter the PC Jr.) Were NOT mentioned and many people do not even remember them. The PC was the first IBM home computer or as it is named Personal Computer or (PC) it even had a cassette tape interface... And while much more limited than todays computers still had more expansion built into it than many newer computers now... (in number of internal slots at least...) I only have 4 of the old PC computers still... Yes they all still work. but not of much use overall... with no hard drive bios updates and such... While 3 slots may be usable to fully expand unRAID, the required drives per expansion card to get all the drives you can use with a PRO key, does then also reduce the models of add-on cards to pick from... TYPO sorry fixed.. chips as in support chips on the MB. There were some combinations of early 64-bit era hardware that would work together, but would not all be truly 64-bit capable... While not needed for most environments likely... I am paranoid, and only have ONE unRAID server opened for use on a different subnet made available for my kids to access. I never know who may bring over a video game console or laptop or other device and connect to my network. So it would be nice to have the ability to further protect the one unRAID that may indeed be exposed to an interal network threat... I do have everything protected in secured back-ups and on secured unRAID servers, but it is a pain to need to use them for what could have been prevented with additional security... (I guess that would be another good reason for 64-bit hardware with more memory etc... running a Linux friendly ant-virus solution on the unRAID box... ) No my MS rant is not related to unRAID, with the exception of just trying to show why an older unRAID may be prefered by some users, while a future version that does not yet exist may finally attract some to upgrade that otherwise may not... I am just saying that depending on the hardware targeted and included in a build that there may be some hardware left out, that might still otherwise be fully usable on a prior version or different build with potentially different optimizations or compromises... (think of the various driver issues with some NIC chips for example, or some IDE and SATA chips...) Sometimes drivers just do not work well, and at times may be best to either not implement at all, or at least use an older more stable software version driver that may not fully utilize a chips capabilities to make it at least usable and stable... The same thing has happened for some CPU support chip sets, and even some early CPU release dies... I do FULLY agree, 64-bit is the future, (at least till an even better path exists...) Tom has provided a very wonderful and robust platform with unRAID. It just keeps getting better too! Just because I prefer the older 4.x look and feel does not mean I am against the 5.x look it is just not what I like, and till I need the new features, (read 3TB plus drive support), I will likely only play with 5.x on test machines... and keep any new real use unRAID builds (with 2TB drives) back on my favorite 4.5.3 version of unRAID. As another side note - for why keep older version available... I just erased all the old data on my old HP Netserver a PIII 933 Mhz machine. In the hopes of making it my oldest hardware running unRAID... unRAID boots fine after booting with a CD boot-strap, BUT it does not have any driver support for my old SCSI cards, so it can not do anything with all my SCSI drives... :-( So it now is running FreeNAS, it works but it is a far cry from unRAID... :-( :-) But now I have a big whopping 250GB array using as much power as a small microwave oven... in a much larger space than a large microwave oven... I probably will be better off to just use an old Celeron 733 Mhz computer and upgrade with some old 250GB IDE drives... then I can run unRAID on it!

Maybe an almost dead thread now... but why do so many people mention the old XT but neglect the earlier PC with only 5 expansion slots instead of the newer very closely 8 slot spacing... (which now most MBs only have two or three of?) An even bigger concern may be with 64-bit... would we need to have BOTH a 64-bit CPU and 64-bit capable support chips on the MB? What about hyper-threading (or the AMD equivillent)? and on the security side of things... what about requiring the execution disable bit in the CPU and bios? My only point here is if making a 64-bit jump is indeed worthwhile, it may be also a good idea to jump up to some higher minimum hardware requirement for security or for other benefits... If such a decision were made for a future 64-bit version, a safer security model could be implemented should viruses or some other attacks like malicious code become a concern on unRAID, or linux in general. This was some of the reasoning that MS with Win8 now requires the disable bit to be available in the CPU and supported and enabled in BIOS. They finally released a version that I was willing to buy to do some upgrades with, since I was still running XP and had not used the newer OSes. I was rather disapointed to learn that MOST of my 64-bit even WITH HYPER-THREADING was too old to allow the use of the new Win8 OS. So I only have a small number of dual-boot XP/Win8 machines compared to what I had planned on. - - thought summery - - Even somewhat newer 64-bit capable hardware, may be old enough to NOT be desirable to lock a future version of 64-bit unRAID to be able to run on. At that point either the older 32-bit versions would need to be used, or possibly a less feature rich/or less secure 64-bit version. Where a more robust higher security model 64-bit version would require substantially newer 64-bit hardware. Oh the fun of aging hardware with new stuff being introduced frequently.... So my ideal unRAID world, in light of the ever changing hardware scene would include multiple available versions as follows: 1. Maintain version 4.7 for an available download. (and also a way to get older versions if wanted...) 2. Maintain version 5.x for an available download (32-bit) 3. Maintain a basic 64-bit version for download (for older 64-bit hardware) (if initial support for this level of hardware is decided as a good idea.) 4. Maintain an advanced 64-bit version for download (for newer bit capable hardware) (for more secure hardware/software options) In the 4 categories it would be, in my perfect world, that all 4 versions would remain available for download and use for many many years into the future. That does not mean that they are all getting updates, just that they are available up to the newest issued released sub-version within that major version group. Some of which may, or may not receive periodic updates of drivers, bug fixes, etc... That way even old outdated hardware would still be able to find a good home in use with unRAID, even if it is no longer hardware that would fit the then newly supported versions of unRAID. New is nice, and may have very desirable features, and reasons to make upgrades of a very large benefit. As long as old is still available for use, both in hardware kicking around, and in unRAID versions for download, not much will truly be left behind or abandoned. Things will of course get to a point where active support may become either un-required or not possible. But in the case of these forums, probably never truly dead either... I have also looked at times to alternatives to unRAID, but I just keep re-evaluating and come back to unRAID as being THE solution for my needs. (ZFS is REALLY REALLY COOL THOUGH, and has some great features I would like to see in the future come to unRAID like multiple parity drives... but more CPU power and memory are needed then as compared to the very humble needs of unRAID) After all unRAID does work quite well on an older P4 with only 256 MB of RAM, and an Intel GB NIC! :-)

You can also do searches for "beep music" I was amazed a few years ago when I was looking around at how many things people have already scripted to play with the beep command! Somewhere I made a menu script to manually select many different songs so I could enjoy them on my little PC speaker. NOTE: the do NOT sound very good if you only have the little piezo speaker like many newer motherboards now have...

If you are having problems with other FLASH drives, be it too large or whatever, yes you can do the following for testing what FLASH drive will work for you in addition to the one you are now using. To not repeatedly power cycle your hard drives, you can indeed unhook them while figuring out and configuring a new FLASH drive for use in unRAID. What I would do is after doing a safe power down of your 4.3 unRAID: 1. Unplug the power from the wall to the power supply. 2. Press the power button on the unRAID server a few times to make sure the power supply is fully drained. 3. open the computer and unplug the power cables from the drives. 4. (optional) note where all the data cables go, so you can put them back later, and unplug the data cables to the drives. 5. After preping a new FLASH drive(s) with the version(s) you want to try to boot, plug it in the the unRAID computer you are trying to upgrade. 6. You can now plug the unRAID power supply back into the wall and turn on the computer. 7. Changes may need to be made to the BIOS settings to make sure that the new FLASH drive is actually in the boot up sequence. 8. After proper configuration, a compatible FLASH will properly boot into the new version of unRAID. 9. You may then browse to to the web interface of the new unRAID version to take a look around with NO other drives connected, or available. NOTE: This test configuration can also be used to add the preclear_disk.sh script and even do some clearing of some new drives in preperation for your final upgraded configuration - usable on this or another computer... I do this on a spare computer so if I have problems with a new drive I do not need to take down an active unRAID server to pull out a new bad drive and replace it and try again... Follow the other recommendations and instructions for upgrades to your active flash you want to turn to pro. You may want to give particular heed to disabling any add-ons you may currently be using under 4.3 so you can properly identify where a problem may be if you should encounter any issues during the upgrades. Have fun! If you take things slowly, there should be no problems.

Here are more details referring to your line item numbers: 1. Each spin up group does have a specific name. Every drive assigned to a specific spin up group will spin up together when that spin up group is accessed. 2. For this example I am using: a. an unRAID server named ur_5rc8a; (unRAID version: 5.0-rc8a) b. a user share named Acronis, with SMB Security Settings: Export: Yes Security: Secure (in ver 4.5.3 was called Export read-only) c. disk1 SMB Security Settings: Export: Yes (hidden) Security: Public (in ver 4.5.3 was called Export read/write) To access for normal READ ONLY protected access: You can browse to the visable path... \\ur_5rc8a\Acronis To WRITE to the hidden path directly to the specific disk: Just add the desired (hidden) disk name in the path... \\ur_5rc8a\disk1\Acronis I find it easier to just use the full paths... not mapping drive letters... NOTE: I specified the exact versions I am using for V5 and V4 in case there are some differences between other sub-versions. but you should be able to see where I am going with it if there are differences on a specific version you may be using that is different from what I am using...

Other past MS OSes sometimes would do the same thing, some it was easy to change after finding the proper sub-menu option to select, which in turn changed the registry entry for the option... Others it was controlled only by a registry key change. Thanks for the registry key! It looks correct! It seems to work properly still in Windows 8 with my tests I just did... (I also just added it to the registration key change list I do with Windows 8 installs.) :-) By the way, it was also the same key in Windows XP, (at least in SP2...) ...and probably also in other versions between XP and Win8

It really comes down to YOUR preferences on how you would like it to work.... If all your user shares are set to use any and all drives, which the one we see is, (which is also the default action)... Then you may want to leave things as they are. One thing you may want to change and/or check is the spin up groups. IF you want the best in power/disk heat-wear - you may want to make sure each disk is in its OWN spin-up group. This will only spin up the one disk which has the specific file you are currently accessing. This will however cause a delay till the next drive is spun up if switching to another file contained on a different disc. For movies it would be likely acceptable... for music it may not be desirable. If you just want everything to work quickly and without spin-up delays once you start accessing files, place all the disks in the SAME spin-up group. This will cause all the drives to spin-up whenever any data is accessed so as you switch to a file from another disk, no additional delay will be seen. For me, I like all my drives in separate spin-up groups. I also never write directly to the user shares, though I do have them enabled. Instead, what I do is write directly to the shared directory after first going to the disk I wish to write to. For example, I have my first disk for TV series that start with the letters A-I. So I have a "TV Series" user share, and in my case \\Tower3\disk1\TV Series then has folders with A-I tv shows in them. disk2 has J-R... This make it easy to make back-ups and do whatever I want with a specific series for maintenance. It also is still very easy to watch anything I want. Since a full series is not spread across multiple drives, there are no delays when switching from one episode to the next either, while still letting the other drive sit quietly without using much power, or generating heat. All my music I keep on a single disk not shared by other files. This works well for me, but may not be the choice for you. One more thing, I have all my user shares set to READ ONLY, and my disks set to READ/WRITE and HIDDEN! This makes it again easy for me to do anything I want, such as updating episodes and fanart, but still not making ready access except to read the files when browsing the server from another computer or media player. Another reason I do this is so I do not need to worry about someone accidentally deleting or altering my files! So what it comes down to, is sitting down and deciding what you would like in an ideal world... then think about how to set up unRaid to best meet those desires! :-)

Glad my post helped to get the info for you to post. It is really hard to see what is happening with all the plug-ins you are running. It also looks to me, like something odd happened after the file system was initially up and running, and the plug-ins were up. (not to mention all the attempted re-running of plug-ins.) It looks like you logged in, or another process did, and stopped services, then attempted to re-launch things again... Then a very long repeating of the file system going up and down, up and down, up and down... Am I looking at this all wrong? I might suggest a clean shut down, then re-boot let everything come up as it might normally do, and DO NOTHING else for about 15 minutes or so... My suggestion would include not accessing the server to do any file operations like reading or writing. Then make a copy of the syslog again and re-post. I would also expect most everyone would also suggest to disable ALL plug-ins for the trouble-shooting process... this may need to be done after another somewhat clean syslog is re-submitted. I think something odd may be happening with Sickbeard, but not sure...

Please do not flame me guys... I think there may just be a case of mis-understanding here. Complicated by a level of frustration of things not working as expected... I will try to help you with the commands "mount" and "df" ... You can try telnet... you can look it up to see what it is and how to use it... OR - - - - - - - use a keyboard and monitor directly connected to your unRAID computer. At the login prompt, login to a console session by using the user name "root", without a password. You will now be at a console prompt (root@YOUR_unRAID_server_name:~# ) After that prompt, type the following: df (then the enter button) The "df" command will then show relevent informatoin needed for assistance. COPY IT EXACTLY AS IT APPEARS and post in a reply. do the same for the "mount" command entering mount (then the enter button) then copy the text response exactly as it appears and post it also. Hope that helps, as I think that possibly you might have been lost in trying to figure out what the linux commands were and how to access them. While basic, I do understand that not everyone may understand what a command prompt, or console session even is... I know that nobody here was trying to give you a hard time, for the sake of doing so at least. But it can be frustrating when trying to help and not getting responses to basic questions to help with the assistance. edit; as a moderator I almost never edit posts that are not my own, but since this user is a beginner, I corrected the commands to be in lower case, and the same with the login name of "root" The original post had them in upper case, and those would have only frustrated the user who is obviously already frustrated. Joe L. :-) Thanks Joe! :-) I also had not even thought about using bolding to properly bring attention to the commands. I had a mindless moment there, not thinking about upper and lower case are NOT the same thing... oops...

With your desire to move that much data, and with the much smaller cache drive you have, I would suggest turning off the cache drive first for the user shares... just till you have completed moving everything over. This will make the process slow compared to what the system will be able to normally do with the cache drive. It will however not cause any problems with the filling of the cache drive, since it will be going to the protected shares directly... assuming you do have a parity drive already enabled on your array. You could also do a test of only a few movie / TV files to make sure everything works as you would expect, BEFORE trying to move everything. You may also want to select a few files or directories at a time such as alphabetically. This way if there is a problem with the process stopping, it will be MUCH easier to figure out what to do next to continue the process. What I do when making large moves of data like that is only COPY the files over, leaving the original files on the original source drives. Then I run a program to verify ALL files that were copied to make sure they are really the same. This also would be a good reason to disable a cache drive before the copy process to make sure that when I do a verification, that the files are actually in the final storage location on the user shares with parity protection. In Windows I use a program called FreeFileSync http://sourceforge.net/projects/freefilesync/ I am not sure if it will run with Apple or not... but there are similar programs available. I just like to make sure I have good copies before relying on a new data storage method. This also will make sure that problems are caught, before any data is lost. I have had bad network cards and network switches I found using this process, where I would otherwise have lost many terabytes of data over the years! Perhaps some may feel I am a bit over doing it, but I would really rather NOT finding out years later that my only remaining copies of my home movies is bad and no longer usable. Other things, though upsetting can at least be replaced.

Good to hear you got things running as you needed!

Currently (2013 Feb 17) I would say you might be better to use the 5.0-rc10-aio since it is still posted as an active download. If there had been serious issues it would have been removed when the newer 5.0-RC11 was released. My thoughts are that it has been in test by more users for a longer period than the RC11 release. It would be good to also read the release notes for RC11 to see if the changes are important to you or not. I really do not feel that either RC10 or RC11 would be a deal breaker though for your application. My 5.0 test machine is way back on RC8a and it is looking very good to me!

A large mountain looks close while yet far away... A walk around the block is very far to an ant... It is all a mater of perspective. All this considered, the RC looks good enough for a test drive, and if it has the features you need/want, would probably be a good move even though it has not been finalized yet. Remember, a RC is already at the state that it is felt that it is ready for release as a fully endorsed version. So even though it is yet looking like the final date is unknown, I would not let that stop me from using the current RC in a new unRAID build and feeling good running it.

ok... yes I understand the confusion. What I would look at to help make a choice comes down to this: SAT2s for like ~$25+ - CHEAP! - Works well but slow with PARITY CHECKS and drive RE-BUILDS in a PCI slot - USE STANDARD SATA CABLES! SAS is like $100 - MORE$ - newer well proven user base - MUCH faster with parity and rebuilds - NEED SAS TO SATA REVERSE CABLES for standard drives connection. SAS2 like $100+ - even more $ - NEWEST, works well for most people - faster again, but not as big of a performance jump as from the SAT2 to the SAS - NEED SAS TO SATA REVERSE CABLES for standard drives connection.

The AOC-SAT2-MV8, which is a PCI-X card which is also compatible with the older PCI bus standard ,that you were asking about is a good card though not as good as the newer ones... They are readily available for CHEAP on eBay also! :-) I am actually going to pick up some of them soon myself due to lack of available PCI express slots and old mother-board reasons... (still running the old 4.5.3 just prior to the safety features being put in to prevent people from blowing away their unRAID drives when they might (in that version) show as unformatted, when they have data on them on power-up... (yes I actually do have good reasons for staying at that scary version level) If you have PCIe x4 (or higher) available, the AOC-SASLP-MV8 is a far better choice to go with however. It is not limited to the much slower PCI bus, so access to multiple drives at the same time will go MUCH faster. The AOC-SAS2LP-MV8 is newer and about the same price as the AOC-SASLP-MV8, so may also have more life for future upgrades with potentially better performance down the road... (but you may want to upgrade to the 5.x platform first since I am not sure at which 4.x version driver support apeared for the newer AOC-SAS2LP-MV8 card.)