NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
dojobel
Nov 30, 2018Tutor
ReadyNAS Pro 4 Kernel Panic
Hi guys,
I've got a ReadyNAS Pro 4 that seems to be kernel panicking on occasion (usually every few days). The LCD will display "_raw_spin_lock_bh+16" when this occurs and I have to perform a h...
- Mar 28, 2019
Hi guys,
Sorry it's a few months down the track now but I thought I better do the right thing and come back in case anyone else experiences this. It looks like with the combination of heavy I/O from the maintenance tasks coupled with heavy I/O on the backup LUN stored on it (there are regular backups every 3 hours) was starving the RAID volume of IOPS and effectively crashing the OS because it couldn't write to it's disks quickly enough. The balance appears to have just been the symptom of that problem.
Unfortunately I can't say anything for certain, but I SSH'd into the NAS and watched it under load and the CPU was really struggling and the load averages were really high. I've adjusted my backup schedules to try and avoid heavy writes during the hours the NAS could potentially be doing maintenance and it hasn't crashed since.
Retired_Member
Nov 30, 2018Hi dojobel, if there is only one vm accessing the nas, I would not investigate much about the error and how to overcome it, but would do the following:
1) Wake up the nas using WOL (wake on lan). You need to allow the wake up on the nas side and on the vm execute a batch containing
...path...\wol.exe <macaddress_of_nas> and a command making the vm wait for a certain amount of time until the nas is up and can be accessed.
2) Use the vm to shutdown the nas following the example in
https://community.netgear.com/t5/ReadyNAS-Storage-Apps-Old-Legacy/WOL-amp-Shutdown/m-p/827132
Of course, that is not a (true) solution, but I would call it a very practical workaround.
Kind regards
dojobel
Dec 01, 2018Tutor
Retired_Member wrote:
Hi dojobel, if there is only one vm accessing the nas, I would not investigate much about the error and how to overcome it, but would do the following:
1) Wake up the nas using WOL (wake on lan). You need to allow the wake up on the nas side and on the vm execute a batch containing
...path...\wol.exe <macaddress_of_nas> and a command making the vm wait for a certain amount of time until the nas is up and can be accessed.
2) Use the vm to shutdown the nas following the example in
https://community.netgear.com/t5/ReadyNAS-Storage-Apps-Old-Legacy/WOL-amp-Shutdown/m-p/827132
Hi mate, thanks for your input! Unfortunately the VM needs 24x7 access to the NAS, so even though it's a single VM, uptime is still very important for this NAS. The VM is driving my backups which run every few hours during the day, then overnight the NAS has some idle time so it can run scheduled maintenance tasks and such.
I originally thought this problem was due to a lack of RAM, however it has been occurring since the upgrade. I checked the logs after the last crash and noticed a BTRFS Balance task had been started just prior to the crash. I have a ReadyNAS Pro 6 doing the exact same thing, coincidentally:
The only common ground between the two is they are running iSCSI, I'm utilising MPIO and there are 2x Hyper-V hosts that attach to these LUNs.
- dojobelDec 01, 2018Tutor
FYI I've started a balance task to see if I can replicate the crash, will report back.
- dojobelDec 08, 2018Tutor
Okay so the balance worked fine this time, and a scheduled one has since completed as well. I'll keep an eye on this over the next little while and make sure no more crashes occur.
- dojobelMar 28, 2019Tutor
Hi guys,
Sorry it's a few months down the track now but I thought I better do the right thing and come back in case anyone else experiences this. It looks like with the combination of heavy I/O from the maintenance tasks coupled with heavy I/O on the backup LUN stored on it (there are regular backups every 3 hours) was starving the RAID volume of IOPS and effectively crashing the OS because it couldn't write to it's disks quickly enough. The balance appears to have just been the symptom of that problem.
Unfortunately I can't say anything for certain, but I SSH'd into the NAS and watched it under load and the CPU was really struggling and the load averages were really high. I've adjusted my backup schedules to try and avoid heavy writes during the hours the NAS could potentially be doing maintenance and it hasn't crashed since.
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!