crazytony

I had a strange problem with Plex I couldn't really get past so I stopped running it on Unraid. I have 4gb of ram and after a period it used up all the RAM on the system (the whole unraid OS is using about ~160mb for me right now). Even killing the Plex process didn't free up the memory (this was what I couldn't figure out) and after about 3 Plex restarts the whole machine would hang (I think the OOM killer found a not so willing victim like the md process). This happened over the space of a month or so. After the third time of having to do a hard reboot and a parity check I moved Plex to my desktop machine and my UnRaid box has been stable for 6 months. No unmenu, no simple features.

Check the access logs for sejeal.jpg, .htaccess and php.class.php. I've found that in most cases it points me right to the offending page (url params)

Thanks Joe!

I think this is possible but there may be angles I'm not aware of so please let me know if I'm crazy(er): I'm copying from an existing, working, parity-protected array to a new, completely empty array. If I run with the parity drive I'm getting write speeds of 30-40MB/s. Can I remove the parity drive and restart the array in an unprotected state? This will mean unraid won't have to sync two disks when I copy. I am aware this new system will not have parity protection until I rebuild the parity but I'm not really terribly concerned about that because the data origin has protection. After I've done the copy (~30TB), can I re-assign the parity drive then rebuild? Would I miss anything other than parity protection on the new system by doing this?

Phew. Was in a bit of a panic last night wondering WTF was happening. Get up this morning to see it's not just me. I tried my Sandisk Cruzer but since we got that working I didn't try my HP device. I will test that device (without running make_bootable/ copying ldlinux.sys) to see if it also has issues.

Not if your PCI-E slots are filled with HBA cards I have 1 spare PCI-E x1 but the SASLP blocks it.

That made it work. That's really strange. Maybe the boot parameters/size changed and that caused the boot loader to go wonky? Tomorrow I'm going to try 8a to see if it is the boot config. That's my normal procedure but when it didn't work I tried the more manual procedure.

ZIP utilizes a CRC to validate the files contained in the archive. The CRC should prevent incomplete archives from extracting properly. That being said, I re-downloaded the archive and went through the process again without any luck.

Well despite earlier enthusiasm 10 will not boot. I can't provide a log because it doesn't get past the bootloader (the SYSLINUX...) Steps: 1. Working 8a stick 2. Power down 3. Transfer stick to PC 4. Copy BZROOT/BZIMAGE for rc10 5. Transfer stick back 6. Boot 7. Hang on bootloader (Syslinux copyright Peter Anvin... etc) 8. Power down 9. Transfer stick to PC 10. Load BZROOT/BZIMAGE for rc8a 11. Transfer stick back 12. Boot 13. Working rc8a unraid Same machine, same stick, same process (copy bzimage/bzroot): 8a works for me but 10 just won't boot. ASUS F1A75V-Pro/4GB ram/2x AOC-SAS2LP-MV8/10 3TB Seagates

Capital A Awesome! I can't wait for final. It's going to be hard to find cost-effective non-realtek solutions in the general market. I tried when building my latest system (in December) due to the realtek issues but all the boards I could find had a Realtek chipset.

I would think that attaching sinks would void your warranty. That being said, if you are not experiencing issues I would not do anything. Just from reading the posts in the last couple of days it looks like the problem may be more complex than a single drive (some of their backplanes had 2 dead mosfets on 2 different ports). I seriously considered getting a norco before I decided to go another way to get to 24. I'm glad that I did though Norco's support sounds like it's competent (shipping out new backplanes like there's no tomorrow).

Apparently the hotswap electronics on the 4224 cannot handle more than .5A draw so some 3TB disks are causing the hotswap to fail which also causes the disk to fail. http://wsyntax.com/cs/killer-norco-case/

NFS stale file handle issues can be caused by a whole bunch of things including the client software not adhering to the protocol for some reason (bug, API incompatibility, etc) as well as issues on the server side (which is why the syslog is important). The original NFS error case that I reported to limetech has been resolved since rc4 and I have confirmed that it is still fixed in rc8a. Do you use a cache drive? The only issue that may or may not be fixed is the NFS issue when you have a cache drive installed. If you can walk through the steps to recreate, Tom can fix the issue.

Can you tell us a little about the scenario in which the stale NFS handle appears and include a syslog? What is the client NFS version?

hmmm Unraid doesn't split files across disks/devices so I'm not sure what's going on. How are you accessing the file? My OpenELEC boxes (NFS mounts) are pretty good about accessing only the files. If the one disk is spun down it can take a couple of seconds to spin up. On Windows, you might want to check your antivirus settings as I've seen laptops attempt to start a recursive folder/file scan when you access a mount (even through XBMC on Windows).