Back in 2011 I bought an Ultra 6 Plus and with the help of a CPU and RAM (to 8 GByte) upgrade, it has been serving me well ever since. It was upgraded to the latest OS 6 and has been serving home directories for my family, running Plex to show movies and music to everybody, and continuously being backed up via CrashPlan.
It has always been rock-solid until a few months ago. Then it started exhibiting mysterious crashes. Every couple of days the device became entirely unresponsive to all services. Looking at the device shows that it has power, but pressing the button does not cause any display like it ought when running properly. The only way to bring it back is a hard reboot.
So I have two questions:
1. Does anybody have any ideas on how to fix this or diagnose this?
There is nothing in the logs to suggest any problem. There have been no hardware changes (except disk upgrades) for years. I have removed the dust buildup, but it was quite minor and unlikely to be the source of the problem. CPU and System temperatures ran a little bit high, but within operating parameters. Nonetheless, there seems to be some correlation between putting heavy load on the system (like a Plex transcode) increases the liklihood of crashes.
2. If it comes to that, how much of a pain would it be to upgrade to new hardware?
I think I'd need a 626X (the lower-end models would mostly work for me but have too little memory and their RAM is non-upgradable!?!). If I buy it diskless, can I just take the disks out of my old system, change the mounting brackets, and insert them into the new system? Remember, they are running the same OS.
Model: ReadyNAS RNDP600U|ReadyNAS Ultra 6 Plus Chassis only
If I buy it diskless, can I just take the disks out of my old system, change the mounting brackets, and insert them into the new system? Remember, they are running the same OS.
I think I'd need a 626X (the lower-end models would mostly work for me but have too little memory and their RAM is non-upgradable!?!).
An RN520 series also has upgradeable RAM (keeping in mind that cracking the case on any desktop ReadyNAS voids the warranty). But of course the RN620 series ships with 8 GB of RAM to start with.
If you have any interest in SSD tiering you might consider an 8 bay unit (giving you two slots you can reserve for SSDs).
You may want to run a RAM test. A bad RAM can cause lock-ups. The power supply is a possibility, though the symptoms don't match that well -- ut they are a common failure on the older units. When the NAS appears to lock up, try to open an SSH shell to see if it's just the GUI session or something more that's locked. If it's alive via SSH, do a top command and see if something is using up all the CPU. I've had readynasd (the main readynas process) go to 100% CPU utilization once in a while, and I think it's usually started by some kind of drive error. It's most common during a scrub or balance (which do use a lot more CPU normally, but not 100% and not for readynasd).
I probably misunderstood this review which said that you couldn't add RAM to mean that the DDR modules were soldered unto the board. Instead I take it they meant that there was only one slot, so you have to replace the one 4 GByte module to add more RAM.
In re: SSD tiering:
It is a neat idea. Unfortunately my current system already full saturates the theoretical maximum transfer rate over GBit ethernet (i.e., about 112 MBytes/second for non-trivially sized files), so I suspect adding SSD caches wouldn't help me any, would it?
RAM test is a good idea. Do you recommend any particular software for RAM test under ReadyNAS OS 6?
As for SSH, the system is totally dead to the world with the only indication of live that the blue light is still on. I couldn't even SSH in as the system at that point has lost its DHCP lease.
[Why run DHCP on 5-minute leases? I run a little demon on another server which monitors a ton of local devices for dropping off the net by checking whether their DHCP leases have expired. When a lot of devices don't have ping or any other service which you could monitor directly, I found this to be the best solution. The IP addresses assigned by DHCP to each device are of course always the same.]
It is a neat idea. Unfortunately my current system already full saturates the theoretical maximum transfer rate over GBit ethernet (i.e., about 112 MBytes/second for non-trivially sized files), so I suspect adding SSD caches wouldn't help me any, would it?
It might help some with folder browsing if you have a lot of files.
I use the 10Gbase-T myself (though only one PC has a 10Gbase-T card in it).
If it's not the RAM and you have a spare ATX power supply "lying around", you can connect that externally and see if it fixes it. The supply will need the 24-pin, 4-pin square, and at least two 4-pin rectangular (old hard drive style) MOLEX connectors. Pull the sides, top, and upper part of the rear off and you can access all the connectors. Put it back together, running the wires out the back, and seal the gap with masking tape. It's an easy way to check if the supply is the issue without investing in the right one (it is available, just not from Netgear) and finding out that's not it. And while you are in there, hit everything with some air to clean it out. Just don't let it over-spin the fans.
I might just have one (or a few) extra power supplies which are still working lying around.
As for dust, that is one thing I already tried. There was very little. On the other hand, it hasn't crashed since I blew that dust out. Of course it has only been two days.
