NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
ReadyNAS Duo v1 boot fail into "Volume scan found and corrected errors"
This is a ReadyNAS Duo v1
-Bootup via Power Timer, as usual, no errors reported or emailed to me -First use of NAS was to stream music to a mobile device. Done it many times, no issues. This tim...
I wouldn't be concerned about lp stat events.
A volume scan is a reasonable idea, though I'd suggest making a backup (or updating it if needed) first.
Did you check system.log and kernel.log for details on what the volume scan fixed? Also, did you look for any disk errors in those logs?
Thanks for reply StephenB. OK I'd been looking in the file system rather than using the Frontview option to download them. I hadn't realised that option would reveal more detail than is shown in the Frontview summary. That said I don't know what I would be looking for that relates to the event that took place. System has not been rebooted since yesterday, as I am offloading content to another drive. Mind you it has shown no signs of misbehaviour nor anything bad in the Frontview health summary since.
Whilst my system is far from new, I have replaced disks for higher capacity in its life, and regularly give it a blowthrough to shift dust. Mind you heat has never been an issue, and the only times I've had problems before (maybe twice, before I got a UPS) was unplanned power interruption which it recovered from anyway, with no signs afterwards.
It's hard to say if the file system corruption led to the streaming problem, or if the forced shutdown did.
The forced shutdown would trigger a volume scan on startup, and possibly a RAID resync. There could have been some lost (cached) writes, which would account for some filesystem corruption.
Generally - look in system.log and kernel.log for any evidence of system crashes or disk-related errors between the time you had the streaming problem and the time the system was fully recovered.
Also look in disk_usage.log at the fullness of the 2 GB OS partition (/dev/hdc1 if you are running XRAID). Normally the OS partition on the Suo is about 25% full.
disk_smart.log is a good place to look for information on disk health - you can also see the SMART+ stats in frontview (though they will come up blank if you use Chome).
Thanks for the extra information StephenB
Here's part of the disk_usage.log:
Filesystem Size Used Avail Use% Mounted on
/dev/hdc1 2.0G 781M 1.2G 40% /
and regarding disk_smart.log, the most recent instance is dated a few days before the event, there's a lot in there that does not grab my attention, mostly as I'm not familiar with entries that could be a concern. I can see however references to SMART health tests stating
"Passed" and "no errors logged"I guess it'd be a good idea to look at the same logs for newer entries once I get round to restarting the system. As I said, I was attempting to stream audio from a device on wifi, which I've done many times before, but this time the software didn't begin streaming as normal and showed a generic error about the device not being available, and it was then I noticed the reboot taking place, and taking longer than usual.
When I had a couple of power interrupts ages ago, something more meaningful showed even in the Frontview Log summary, but this time it merely says "Volume scan found and corrected errors" (severity shown as green) which must have been created on reboot. There is nothing in the Frontview logs immediately before the episode, the sequence showing:
1 System is up (from scheduled start)
2 System powering off...
3 System powering off...
4 Volume scan found and corrected errors.
5 System is up.I'm assuming entries 2&3 result from my mashing of the power button to restart it (after not getting any error warnings via email - I've also just tested the alert function, working ok)
What I have noticed in looking at the content of SMART+ via Frontview is that for Disk1, the Lp stat events count seems higher than I recall. Disk 1=156 whereas Disk2=4. BTW both disks were installed at the same time. Not understanding that I looked it up and the suggestion is that relates to IO taking longer than expected (a symptom of the failed streaming "calls"?)
For ref the thread I'm looking at is
https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Lp-stat-events-What-does-it-mean/td-p/969417so following that I checked
Reallocated sector count
Current Pending Sector
Offline uncorrectable
ATA errorsAll of the above have a zero count, both disks
I'm still copying data to other drives, not the fastest connections, but whilst doing that there has been no untoward behaviour at all
It does seem highly coincidental that the system auto started without any errors and the issue started when the media streamer misbehaved. Is it possible this somehow upset the NAS, and without an error alert, my manual interruption recommenced any recovery that was ongoing? It'd be nice if I've dodged a bullet on this one....
OK I just restarted the system and it's up as normal. Nothing untoward showing in Frontview at all.
Checking that Lp stat events counter again, both disks now show 6 and 5, hugely different from before.
Tempted to restart with a volume scan at next boot to see what happens....
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
