PeterB

However, all of your figures are rather worthless if you don't say what the temperature of the air is which is being blown by the fan. If you notice, I was quoting drive temperatures when the ambient air temperature was 33C. In that circumstance I would be unable to maintain my drives 'in the low 30s' without some form of refrigeration.

I hadn't heard of these plans before. If XBMC (and OpenELEC?) really do abandon SQL in favour of uPNP, I will be looking for a new solution.

As far as I'm aware, Tom has not been able to characterise this issue yet. There are reports of X9SCM systems being affected by this problem, but there are also reports of X9SCM systems which do not seem to be affected. There have also been reports of a couple of other systems (not Supermicro) which would appear to be suffering from the same problem. I have not seen any reports of X9SCL or X9SCM-ii (which is what I use) being affected.

It is? I have this mobo and I don't receive random reboots, can I ask where there's a discussion on this? And what the symptoms are? And if it's going to be fixed? I didn't say that the 'random reboots' were a known symptom, but it's suspicious that the OP appears to have resolved the issue by restricting available memory, making me believe that there may be a connection. Very slow writes is definitely a symptom of the X9SCM/>4GB problem. To the best of my knowledge, Tom is still investigating this. What my post was really getting at was the Windows mentality of - "There's something wrong with my computer, I'll have to format and re-install". The only issue that this approach is likely to address with unRAID would be if the flash drive is failing.

If I was buying now, I'd definitely go with the iStarUSA BPN-DE350 - the all metal construction should be a little more solid than the previous model which I have. Also, I'm guessing that ventilation holes on the doors are a little less obstructive, allowing better airflow. I wouldn't worry about the standard fans on a drive cage - I removed mine and rely on the case ventilation to draw air in over the drives. This certainly works because, even during parity check, my drive temperatures remain at 7-8C above ambient. That is, with an ambient temperature of 33C the other day, my drives stayed at 40C. With temperatures that high I like to take it easy - but my unRAID server keeps working away!

No.

Because unRAID boots from Flash, and runs with a memory disk as system drive, 'starting over' is usually unnecessary - it's not like have to format and re-install windows. In any case, there is a known problem in rc12 with the motherboard you're using and more than 4GB RAM - 'starting over' is unlikely to make any difference. Also, I understand that there is a performance problem with Simple Features and RC12 - the developer is looking inti this.

Why do you have to 'wait for it'? As far as I am aware you can carry on using OpenELEC/xbmc while a library update is running.

Yes but, strangely, the dropped packets occur on the reverse link - ie, tx file from unRAID server (1Gb) to a 100Mb client and the dropped packets occur on rx at the unRAID server. Yes. Yes. But having two intervening switches effects a drastic reduction in dropped packets.

I'd guess that the intention is that it runs when the server isn't in prime time use. Mover can certainly cause a slow-down in normal network serving activity.

The other thing to consider, if you run your system from a UPS - you don't want a UPS-controlled shutdown to be delayed by your mover process.

Indeed, yes. In fact, rather than 'get away with' treat the onboard ports as your best interface. Even if it's 'only' SATA2, the on-board ports are probably the best-performing ports in real life, with lowest system overheads. I will always recommend a Seasonic unit but any 'good' psu will do fine, as long as it has only a single +12V rail. Seasonic tends to be expensive - the Corsair range are usually more affordable, and widely used in unRAID builds, particularly the CX430 for 'smaller' systems.

JoeL will be the best person to answer this, but I'm pretty sure that the script does access some unRAID configuration file(s). But why don't you examine the script? I suspect that a lot of the disk manipulation uses the dd command. You could create your own script, possibly based on preclear, to achieve what you need. You comment hat 'zero them out is not needed for an unraid setup', but I think that is exactly what preclear does, together with creating the MBR in a specific form.

Okay, fair enough. Whether you allow the correction of parity errors depends on whether you trust the contents of all of your data drives to be good. If the parity errors are the result of a bad data drive, then running a correcting parity check will destroy your parity and, therefore, your chances of getting a good restore onto the new drive. If you have no reason to be suspicious of the content of the parity drive (like if the system suffered a sudden powerdown while data was being written to the array), I think, in your situation of having a known failing data drive, I would trust the content of the parity drive and NOT, under such circumstances, run a correcting parity check. From the fact that you asked the question, I'm guessing that you don't fully understand how parity works and what it means when the system reports that there are parity errors.

Did you check the logs to ascertain the cause of the failure. Did you check the smart report and address any problems identified? If not, I think that you were living rather dangerously! Actually, you should have had another option (which would leave the array without parity protection, but might well be safer than continuing to use a known failing drive) - the array will start and run perfectly well, albeit slowly, with one drive missing - the contents of the missing drive will be simulated from the contents of parity and all the other data drives. Just as well it's non-correcting! You would be very ill-advised to rebuild one data drive when another drive is already known to have errors! I'm sure that you can do the preclear with the array stopped, so no other drives ought to be active, which would give them a high degree of protection. If you are really desperate to have the array up and running, I think, in your situation, I would risk replacing the failed drive with the new one, without waiting for the preclear. A new drive has a better chance of working than a known faulty drive! The rebuild will write to ever sector on the new drive, so checking the syslog and smart reports after it completes would give some degree of confidence. Definitely throw it away ... unless you value your data at less than the price of a new drive!

I was thinking along similar lines - I know that unRAID is often promoted as 'being able to run on old hardware' but, in this case, the network interface is no go, the disk controller is no go, there's not even built in video ... what are you gaining from your old mobo - a socket for the cpu?

So the only thing you hope to achieve is that the library will be updated without manual intervention? I always run the library update by by hand but, as I say, I do this on any box, even a desktop computer. Doesn't xbmc have an option to run the library update on a periodic basis and/or on system startup ... would this not be sufficient for your needs?

Okay, you posted while I was typing my reply, but I'll let it stand as is: Indeed, it's not clear what you hope to achieve by running xbmc on the server. I run OpenELEC media boxes - all the movies, the database, the thumbnails etc. are all stored on a shared central resource on the unRAID server - I even boot from unRAID via PXE (network) boot. My OpenELEC boxes don't have any local storage - no drives, not even a flash drive. If I perform a library update, the library is automatically updated for all boxes. Sometimes I will perform a library update without turning a TV on, by running XBMC on a desktop computer. If I stop watching a movie, part way through, on one box, I can go to another one and it will automatically continue from where I stopped on the first box. My boxes are running the same hardware, so if I update the OpenELEC version on the server, all boxes are updated automatically. So, the question, again, is: What are you trying to achieve - anything I cannot do?

If you google 'empty ipi mask' you will see that there have been recent linux patches to eliminate false 'empty ipi mask' warnings. I would simply ignore it.

So, if I understand your requirement correctly, you're wanting to add a remote drive to an unRAID user share?

As I was typing my previous reply, I noticed that my current dropped packet count was only 106 - much lower than I've seen since I noticed this problem. So, I did a file copy through wireless interface and was astounded to find that the dropped packet count didn't increase. I wondered what had changed - I then remembered that my 'temporary' switch was still in place with only two connections - my unRAID server and my main switch. I moved the unRAID connection back to my main switch and, even without a file copy, other network activity was causing the dropped packet count to shoot up - several thousand in less than a minute. I moved the unRAID connection back to the 'temporary' switch and the dropped packet count stopped incrementing again. My rationale for this is that there are now two switches in the link, both of which are buffering packets. So, it seems that this problem can be ameliorated, if not fixed, by increasing some buffer somewhere. More investigation and testing seems in order! To bkasten - it would seem that any device connected via one of your subsidiary switches is not going to contribute (significantly?) to the dropped packets.

Gary, to provoke this problem you must, first of all, be transmitting data from the unRAID server (1Gb ethernet interface, I assume) to another device which has a slower interface (eg 10 or 100Mb wire, or a wireless connection) - this can be a simple file copy from a standard disk or user share. You can check for dropped packets via a telnet connection to your server - simply type the command: ifconfig eth0 before and after the data transfer. If you have this problem, it will show up as an increase in dropped RX packets (fourth line of the output - see bkasten's example in reply #18).

... all connected to a Gb switch - are you sure that they have all negotiated a Gb connection? What about wireless clients? What about Internet traffic? You could try disconnecting all clients, one at a time, including disconnecting your router, and note whether the dropped packets stop. Apart from two older computers which have 10/100 interfaces, I also have several Squeezeboxes (both 10/100 hardwired, and wireless) and a digital photoframe on a wireless connection. I honestly cannot remember whether my TVs, set-top boxes etc. have Gb or 10/100 interfaces. To make life easier, I performed a lot of my testing with just two connections to a spare switch. Okay - worth doing as an experiment, and simply accomplished with an ethtool command: ethtool -s eth0 autoneg off speed 100 duplex full Restore Gb operation with: ethtool -s eth0 autoneg on speed 1000 duplex full Exactly what I'm seeing. This makes me think that you have some background process passing packets to a slower interface - perhaps the Internet. My dropped packet counts increment much more rapidly while I have transmission running, or during file transfer to a slow machine. As I said before, I had assumed that the on-board NIC was going bad. Nothing new there for me. So I ordered an Intel Pro/1000 card to put in. Now I am not so sure. Me too! Sure, it's worth a try!

Thanks Weebo, that's good to know. I'm using a G2, but I could get a G3 for my second licence.

... and if you follow this sub-thread back to its origin, you will see that it relates back to MSattler's RMAs of a set of drives nearing the end of their five year warranty. I wasn't questioning replacement of newer drives, although I would think twice about an RMA of my two year old EARS drives - I would probably prefer to replace them with EARX or Red (if I can obtain them here) drives. I have a 1TB EADS sitting on the shelf, which failed during its warranty. Part of my reluctance may stem from the fact that I have to ship my drives internationally, from Philippines to Singapore, in order to claim a warranty replacement.