This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
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 hard reset.
The NAS has been upgraded to ReadyNAS OS 6 (currently running 6.9.4) and I've increased the RAM from 1GB to 2GB (the maximum that the chassis supports according to dmidecode).
The NAS is purely an iSCSI Target, storing backup data (so there's only one VM accessing it). It's configured in RAID-5 and has 4x 1TB 7.2K SATA disks in it. The volume is encrypted, if that makes a difference.
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.
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
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
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:
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.
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.
