NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Ready NAS2100 Drops from Network
I have 4 of these devices, one of them seems to drop off the network. Its physically on and has green power lights but the blue disk lights are off, the web interface is offline and it does not ping, only way to get it back online is to hold the powerbutton down and powercycle it.
I've looked through the logs, corrected smart disk errors etc, but cant seem to see anything in the logs which indicate somthing happening.
I have no sleep/spin down settings set etc.
Latest one occured somewhen between 19th and the 25th of March
From the web console it appears to have all the same settings as the others which function perfectly.
Tried to attach my logs but it errors as they are not jpg...
- The file system_log-hd-nas1-20190325-110914.zip does not have a valid extension for an attachment and has been removed. jpg,gif,png,pdf are the valid extensions.
6 Replies
Replies have been turned off for this discussion
Hi Helin0x
I think the issue is either disks or chassis. It could also be the fact that the volume is 100% full. Anyway, here are some things that stand out.
You are using two "Green" drives and they have recorded plenty of command timeouts, which is bad. One disk is also constantly recovering from ECC errors. I would advise to not use Green drives in a NAS at any time. They spin down on their own and they have aggressive power management - all if which is bad in a raid and will cause things like command timeouts.
Model Family: Seagate Barracuda Green (Adv. Format) Command_Timeout: 26 Hardware_ECC_Recovered: 750873864 Model Family: Western Digital Caviar Green (Adv. Format) Command_Timeout: 55
We can also see that the NAS struggles to communicate with those drives, at times.
Sep 28 06:38:51 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Sep 28 06:38:51 kernel: ata4.00: failed command: SMART Sep 28 06:38:51 kernel: ata4.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/40 tag 0 pio 512 in Sep 28 06:38:51 kernel: res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Sep 28 06:38:51 kernel: ata4.00: status: { DRDY } Sep 28 06:38:51 kernel: ata4: hard resetting link Sep 28 06:38:51 kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Sep 28 06:38:51 kernel: ata4.00: configured for UDMA/100 Sep 28 06:38:51 kernel: ata4: EH completeYour volume is 100% full and that is a problem on its own.
Filesystem Size Used Avail Use% Mounted on /dev/md0 4.0G 405M 3.4G 11% / tmpfs 16K 0 16K 0% /USB /dev/c/c 5.5T 5.4T 11G 100% /c <<<=== Data volume
It can lead to filesystem corruption and your filesystem certainly seems to have regular issues. Some examples:
Feb 24 00:00:05 kernel: EXT4-fs (dm-3): INFO: recovery required on readonly filesystem Feb 24 00:00:06 kernel: EXT4-fs (dm-3): write access will be enabled during recovery Feb 24 00:00:09 kernel: EXT4-fs (dm-3): recovery complete Mar 3 00:00:07 kernel: EXT4-fs (dm-3): INFO: recovery required on readonly filesystem Mar 3 00:00:07 kernel: EXT4-fs (dm-3): write access will be enabled during recovery Mar 3 00:00:11 kernel: EXT4-fs (dm-3): recovery complete
I would recommend the following:
- Take a backup of your data if you don't have a backup already.
- Take some data off the unit. Try not to go above 90%-ish.
- Replace those Green drives with some actual NAS drives. Remember to replace with disks of same size or larger and replace one at a time --> leave the raid finish sync --> replace next one.
- See how it does after that. It could also be chassis related but rule out the obvious suspects first.
CheersThanks for checking over my logs
The capacity is due to it being an iscsi lun using all bar 10GB, as this is a set size the volume will never grow, this is also a common set up amongst the other readynas 2100 I have which dont exhibit this behaviour, in this scenario do you believe this would it still cause a problem?
The others I have are not using green disks, I had greens lying around so used them to replace failed HGSTs to save on costs (these are only old archive data at this point), I think you can hack them with widdle3 to stop the self spool down but I'll just replace them with more HGST and see how it goes.
I think the file system corruption was down to a failed disk in slot 1, it had a few hundred reallocated sectors, replaced this on 19th March and it subsequently passed the volume check:
Tue Mar 19 14:23:19 WET 2019 Data volume will be rebuilt with disk 1. Sun Mar 24 00:08:23 WET 2019 The on-line filesystem consistency check completed without errors for Volume C. Was hoping that replacing it would put this issue to bed and but it was still putting the device offline, so here we are.
Hey
It does make it slightly better that it is an iSCSI LUN. 100% is prob still a bit high. You can't shrink it anyway so only choice is to leave it as is. For the future, I would leave 2-3% free space when using the iSCSI LUN. It just gives a little wriggle room. To give comparison, the new line of NAS will not allow you to create a LUN larger than 90% on the total volume size.
Yea, the green drives are a pain. All those command timeouts, etc. They are just always problematic in a NAS scenario. On the other hand I do understand desire to keep cost down as it is essentially an archive solution at this point.
The FS issue could easily have been down to that disk. I guess only time will tell. Just keep an eye on it. Other than that, I didn't see much wrong with the NAS. As said, could be chassis as well or a slightly dodgy power supply. But let's hope not :)
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
