NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
RN314 problems after Readynas 6.10.7
After install of 6.10.7 (apparently trouble free) on a RN314 (4*6TD WD drves) that has been in use for years, the gui degrades to the point where no data appears in the admin page. In the short time...
alfb wrote:
So should I hot swap sdb (drive 2 as 1,2,3,4) or is it sbd (drive 2 as in 0,1,2,3) The output from mdstat infers drive numbers are 0,1,2,3
And are these numbers from left to right as looking from the front??
One caution is that the error in the screen shot is a read error - normally if mdadm is rebuilding a disk, it is writing to it. So there still is some uncertainty on exactly what is going on.
sdb is normally the second disk from the left (the disk in the first slot normally is sda).
If you aren't certain, you can also get the serial number with smartctl -x /dev/sdb (along with a lot of other information). Then you could power down the NAS, check the disk serial, and boot up the NAS read-only without it. If the volume is there, but degraded, then you could reboot again normally. Then do a hot-insert of the replacement.
Instructions on booting the NAS read-only are on pages 74-75 here:
StephenB,
Thanks for this recommendation. I used journalctl -r and found many references to errors on sdb and sdb4 .
The only way I know to show others is with a screen shot so my output is in .png format. But this limits me to a single page.
So should I hot swap sdb (drive 2 as 1,2,3,4) or is it sbd (drive 2 as in 0,1,2,3) The output from mdstat infers drive numbers are 0,1,2,3
And are these numbers from left to right as looking from the front??
I am still seeing ~7.5% completion on the resync after 4ish days. So waiting for a completion may see me being a very old man.
If swapping sdb ends in failure, I guess my next step is to do the factory reset reboot?? Or is there a wiser way?
Regards, and thanks, Alf
alfb wrote:
So should I hot swap sdb (drive 2 as 1,2,3,4) or is it sbd (drive 2 as in 0,1,2,3) The output from mdstat infers drive numbers are 0,1,2,3
And are these numbers from left to right as looking from the front??
One caution is that the error in the screen shot is a read error - normally if mdadm is rebuilding a disk, it is writing to it. So there still is some uncertainty on exactly what is going on.
sdb is normally the second disk from the left (the disk in the first slot normally is sda).
If you aren't certain, you can also get the serial number with smartctl -x /dev/sdb (along with a lot of other information). Then you could power down the NAS, check the disk serial, and boot up the NAS read-only without it. If the volume is there, but degraded, then you could reboot again normally. Then do a hot-insert of the replacement.
Instructions on booting the NAS read-only are on pages 74-75 here:
Hello StephenB,
Yes the journalctl output seems to be read errors only.
The smartctl output from sda, sdc, and sdd are "snappy" as in they finish momentarily after pressing enter.
The smartctl output from sdb takes minutes to finish and does indicate a large number of read errors. The serial number as reported by smartctl matches the serial number in the error log.
Re " If the volume is there, but degraded, then you could reboot again normally. " Since my access to the gui is unreliable, is
cat /proc/mdstat
a good place to verify "the volume is there'?
Regards and thanks, Alf
The NAS does a MDADM re-sync when it does a BTRFS scrub. Maybe that's what kicked it off. What does btrfs scrub status /data show?
The sync during scrub is truly at the same time, which causes it to take a long time.
alfb wrote:
Re " If the volume is there, but degraded, then you could reboot again normally. " Since my access to the gui is unreliable, is
cat /proc/mdstat
a good place to verify "the volume is there'?
The web ui should respond normally after you boot up read-only, as it is pretty clear that the performance issues are related to the disk errors.
So one way is to look at the volume page in the web ui when you boot up read-only.
- If the volume is marked as degraded, you can then make sure the data is accessible from a PC. If it is, just reboot normally
- If the volume is marked as "inactive" or dead, then the system is trying to rebuild another disk. In that situation, you need some form of data recovery. I don't think that's likely, as the commands we've already run normally will show you what disk is rebuilding. While this scenario is possible, I don't think it makes sense to wait for the resync to complete.
You could also check with ssh:
- cat /proc/mdstat will tell you the status of the raid groups
- Examining the data volume will let you know that the data volume is mounted and that the data is accessible - for instance ls /data should show you the shares (if you are using data as the volume name). Similarly, ls /data/sharename should show the files and folders in the share. If ls /data doesn't show the shares, then the volume failed to mount.
StephenB: I will proceed with the steps you outlined.
Sandshark: output of btrfs command
root@CTS-NG314:/proc# btrfs scrub status /data
scrub status for 9f66362a-5347-4ccb-9950-77ab32406926
no stats available
total bytes scrubbed: 0.00B with 0 errors
root@CTS-NG314:/proc#StephenB and Sandshark,
The replacement of the drive and rebuild completed successfully around 03:30 am, and elapsed time of 15 hours. Reliable access to the gui right after drive replacement.
In summary, perusing the log, showed drive had been reporting errors since July, but email notifications were not working so I missed them!
My inference in the subject line that the upgrade to 6.10.7 was implicated was totally off base!
Thank you for your interest and guidance.
Alf
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
