I recently discovered that my Reaynas 102 does not seem to handle moving files very well. If I try to move a ~200GB folder from one share to another on the same NAS, it eventually freezes up and a complete hard reboot (unplugging and replugging the power cord) is the only thing that will get it back up and running again. Before the freeze, I run into "unspecified network errors" from Windows.
I'm well aware that this model by no means is for "heavy duty" use, but surely it should be able to handle simple file moving?
What I have tried to far is to give the unit a thorough cleaning with compressed air. This brought cpu temp down from ~68c to ~60c, and now it seems to handle things better, so maybe it's a temperature issue?
If so, I was wondering if there's a noob-friendly way to make the fan a bit more agressive? Mine seems to always hover around ~800RPM no matter what. And I very much prefer stable operation over silence.
Any help appreciated.
Model: RN10200|ReadyNAS 100 Series 2- Bay (Diskless)
I agree your copy should simply have worked. I just reset my RN102 and restored ~4TiB of data with rsync with no problems.
If you think this hardware related, you could try getting an RMA. Though maybe someone here will want to see your logs (which might help if you need to convince support that an RMA is justified).
Do you know what the temps were for your restore? Mine was like 68c and I'm suspecting that might have been the issue. temps are currently ~60c after the dust removal, and things seem to progress smoothly for now. But I'd also be interested in a way to get the fan speed up, as ~800 is obviously not enough to keep the cpu cool in my environmemt.
Edit: I spoke too soon. Same behavior now, even though the highest temps I saw this time was 64c, so it's probably not the temps at all.
Setting MTU back to 1500 does seem to "fix" the issue so it probably is a bug with how Jumbo Frames are handled by the NAS. Do I file a bug report or what's next?
For Jumbo Frames to work well all your devices need to support them and you need to have the appropriate MTU set on your devices.
It is also worth noting this:
Skywalker wrote:
However, the benefits of jumbo frames on RN10x are questionable at best. The Marvell chipset used in RN10x is not capable of doing TCP checksum or segmentation offloading on packets larger than 1600 bytes. So you'll usually experience much better TX performance with a smaller MTU.
So an MTU of 1600 would be better than 1500? All my devices do support jumbo frames but if the chipset is incapable of benefiting from MTU bigger than 1600, maybe it shouldn't be a choice in the GUI to begin with. And even if there is no benefit to 9000 byte jumbo frames, the device shouldn't "crash" from it, right?
I am perfectly OK with jumbo frames not being supported by the chipset as it's more of a "cost effective" series of NAS, but I do believe the crashing and network errors is something that should be looked into.
No. The packet per second reduction is marginal, so you are better off running standard ethernet (jumbo frames are commonly used, but are not part of the ethernet standard).
In an ideal world I think it would. The CPU is weak so any job that it doesn't have to do should, in theory improve performance. I've left it at 1600 for now as I see an improvement in performance compared to 1500. It's not "huge" or anything but it's there. And while it might be trivial for copying single files here and there, I'd immagine it will actually save time when hundreds of gigabytes are copied.
And I'd like to file a bug report also.. Just because a feature might not improve performance if activated doesn't mean that it's OK that it's left broken. If Jumbo frames makes no difference and the feature can't be implementet properly it'd be better to just remove the choice to enable it.
I'm running transmission with 5 torrents seeding, seeing an average upload of ~200MB/day.
The odd input is because I tried finding the max value, which the system doesn't tell you is 9600-ish... But I think it was autocorrected upon reboot. That's probably another area that could be improved. It's silly that you can input such great numbers when the maximum that can be set is much smaller.
If the crash is caused by an out of memory issue it's probably something with the file transfer. Maybe some cache that isn't flushing properly since it happens when copying files from the nas to the nas but doesn't seem to happen if files are copied to or from another device.
Just so I don't do stuff that isn't asked for... You want me to disable transmission, re-set jumbo frames to 9630 or whatever the max value is, and try to copy the same large folder again and see if there are the same network errors or crashes that I previously experienced?
Just so I don't do stuff that isn't asked for... You want me to disable transmission, re-set jumbo frames to 9630 or whatever the max value is, and try to copy the same large folder again and see if there are the same network errors or crashes that I previously experienced?
Note I don't work for Netgear - I was mostly wondering if you'd tested it w/o transmission. If your system is stable now, you could just leave it alone.
But if you do want to see if transmission is related, you could try disabling transmission, resetting the MTU to 9000 and testing the file transfer again.
I'm not sure what the max MTU is in the NAS, but 9000 is the most commonly used JF size. There is always some ambiguity as to whether MTU setting means the max ethernet frame size or the (slightly smaller) max IP packet size. So it is always best to check the path MTU with ping to confirm the MTU settings act as desired.
FWIW, you could also run a ping test to see if the crashes or network errors recur. For instance, with windows
ping -f -l 8972 -t NASIPADDRESS
That will send 9000 byte packets until you stop it with ctrl-c.
