NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
dstsui
Apr 28, 2021Aspirant
RN102 broken after OS 6.10.4 update
My RN102 appears to be broken after updated to 6.10.4. Not sure which came first, I updated the OS to 6.10.4 and noticed very slow transfer speed when I copied hundreds of JPEG images from the SD car...
StephenB
Apr 28, 2021Guru - Experienced User
dstsui wrote:
I downloaded the log System_log-nas-36-1C-14-20210429-072924.zip this morning but I don't know exactly what to look for. The Log page in Admin looks fine to me; no error, no warning. By the way, the OS was updated on 25/4 6:39pm but the log was not retrieved until 29/4 4:7:29am so there is big chunk of information missing. The only app installed is Transmission.
I redacted your download link (the full log zip shouldn't be posted publicly). But I did take a look.
kernel.log has a lot of errors on disk 1 (sda). For instance, this segement
Apr 27 10:30:23 nas-36-1C-14 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 27 10:30:23 nas-36-1C-14 kernel: ata1.00: irq_stat 0x40000001
Apr 27 10:30:23 nas-36-1C-14 kernel: ata1.00: failed command: READ DMA EXT
Apr 27 10:30:23 nas-36-1C-14 kernel: ata1.00: cmd 25/00:40:a8:6d:2b/00:05:67:00:00/e0 tag 26 dma 688128 in
res 51/40:0f:d8:70:2b/00:02:67:00:00/e0 Emask 0x9 (media error)
Apr 27 10:30:23 nas-36-1C-14 kernel: ata1.00: status: { DRDY ERR }
Apr 27 10:30:23 nas-36-1C-14 kernel: ata1.00: error: { UNC }
Apr 27 10:30:23 nas-36-1C-14 kernel: ata1.00: configured for UDMA/133
Apr 27 10:30:23 nas-36-1C-14 kernel: sd 0:0:0:0: [sda] tag#26 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 27 10:30:23 nas-36-1C-14 kernel: sd 0:0:0:0: [sda] tag#26 Sense Key : Medium Error [current] [descriptor]
Apr 27 10:30:23 nas-36-1C-14 kernel: sd 0:0:0:0: [sda] tag#26 Add. Sense: Unrecovered read error - auto reallocate failed
Apr 27 10:30:23 nas-36-1C-14 kernel: sd 0:0:0:0: [sda] tag#26 CDB: Read(10) 28 00 67 2b 6d a8 00 05 40 00
Apr 27 10:30:23 nas-36-1C-14 kernel: blk_update_request: I/O error, dev sda, sector 1730900184
Apr 27 10:30:23 nas-36-1C-14 kernel: md/raid1:md127: sda3: rescheduling sector 1721199976
I suggest powering down the NAS and testing it in a Windows PC (either connected with SATA or a USB adapter/dock) with Lifeguard.
Alternatively, you could try rebooting the NAS w/o it, (leaving disk 2 in slot 2), and see if you get a more normal speed.
When you replace the disk, avoid the WD20EFAX - it is an SMR drive. A Red Plus drive (another WD20EFRX or WD20EFZX) would be fine.
dstsui
Apr 28, 2021Aspirant
Will the NAS boot up with disk 1 taken out? Did you observe similar errors in disk 2? How likely is the NAS hanging up when reading/writing multiple files caused by errors in disk 1?
Re HDD dock, do you mean something like this? What is Lifeguard? Can Windows read the files directly?
- StephenBApr 29, 2021Guru - Experienced User
dstsui wrote:
Re HDD dock, do you mean something like this? What is Lifeguard? Can Windows read the files directly?
Yes
dstsui wrote:
Can Windows read the files directly?
No, and it won't mount the disk. But Lifeguard will see it, and you can test it.
If you boot the NAS with just disk 2, and then later on want to reinsert disk 1: You will need to resync disk 1, which rebuilds it's contents from scratch. So you might as well also run the destructive "erase disk" (might be called "write zeros") test as well as the non-destructive tests I suggested.
If you want the option to reinsert disk 1 w/o resync, then you need to keep the NAS powered down until you test the disk. But given the errors, I'd just replace the disk.
dstsui wrote:
What is Lifeguard?
Western Digital's diagnostic utility. You can download it from here: https://support.wdc.com/downloads.aspx?p=3
Though it looks like they've replaced it with a newer utility ( https://support.wdc.com/downloads.aspx?lang=en&p=279 ), so you could try that one. But Lifeguard will still work.
- dstsuiApr 29, 2021Aspirant
Please confirm the following action plan is sound with low risk:
- Remove Disk 1 - should I remove the disk when the NAS is live or is it safer to remove it when it is powered down?
- Power on the NAS with just Disk 2. Run speed test using NASTester and confirm the system is operating properly without hanging up.
- Power down the NAS and insert Disk 1 with a new HDD into the bay.
- Power on the NAS and let it resync and rebuild Disk 1, assuming this is all automatic.
- When resync is complete, run speed test again and confirm the system is operatng properly without hanging up.
- Insert the failed disk into a HDD dock and examine it with the WD utility as an optional exercise.
Some HDD docks have two disk slots and can do disk cloning. Is it okay to clone a disk from Disk 2 using the dock or is it better to leave this to the NAS?
How come the disk_info log attached shows no disk errors but the kernel log logged disk errors? Does Channel 0 corresponds to Disk 1?
- StephenBApr 29, 2021Guru - Experienced User
Lowest risk would be to add a step to back up the data on the NAS (for instance to a USB drive). This could be done before step 1, but it likely will go faster between step 2 and 3.
dstsui wrote:
Please confirm the following action plan is sound with low risk:
- Remove Disk 1 - should I remove the disk when the NAS is live or is it safer to remove it when it is powered down?
It doesn't really matter - but you probably should confirm that the NAS boots normally with only disk 2 in place. So maybe power down.
dstsui wrote:
3. Power down the NAS and insert Disk 1 with a new HDD into the bay.No need to power down here. Hot-insertion is fine.
Generally I test new disks before I add them to the NAS. What I do is test them with vendor diags in a Windows PC - running the full non-destructive "long" test, followed by a full erase/write zeros test. I've received some new disks that pass one of those tests but fail the other.
dstsui wrote:Some HDD docks have two disk slots and can do disk cloning. Is it okay to clone a disk from Disk 2 using the dock or is it better to leave this to the NAS?
I wouldn't. If you run the NAS with only disk 2 in place, you still need to do the resync. Cloning is sometimes a necessary part of data recovery - but if there are sectors that can't be read, there will be some garbage on the clone. Since there are no read errors on the new good disk, the NAS has no way to tell which sectors are garbage.
dstsui wrote:
How come the disk_info log attached shows no disk errors but the kernel log logged disk errors? Does Channel 0 corresponds to Disk 1?
That is an excellent question. You'd think it would show up in the SMART stats. But I've seen this before, so I know errors don't always end up in those stats.
SMART stats are kept by the disk itself - the NAS just asks the disk for them. So this is either a limitation in SMART itself, or something not quite right in the disk's statistics collection.
The disk is over 6 years old, so you have gotten your money's worth out of it.
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!