NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
EDA500 on RN516 - Scrub very slow
This problem has been previously reported by another user on an earlier version of the OS: ReadyNAS-516-2x-EDA500-Scrub-on-EDA500-very-slow. It persists in OS6.7.5. As scheduled, my main data vo...
Thank you so much for this post, as I was thinking I was the only one with this issue. Aparently you an I were the only ones who purchased the EDA500 :) I too am having this issue... I was likely the one you referenced as another user, but I have had this issue across multiple versions and across multiple factory defaults. In fact, after hearing that a factory default may help I purchased a RN316 + 6x8TB drives (yep quite a bit of money). This purchase was soley to backup the RN516 volumes and factory defualt it. I did this and built the volume on the EDA500 with 5x WD60EFRX drives, effectively 16TB in size. The volume created on the RN516 in less than 2 days time. Since then I have copied all my data back and been running successful, all the time thinking I have fixed the issue. It has been a few months, so I figured I should run the defrag, balance and yes, the scrub on the volumes. I started with the data volume which is 6x wd80EFRX drives (nearly 30TB) in RAID6 and the scrub completed in less than 36 hours (very fast). So I proceeded to start the scrub on the EDA500 volume (eda1). I started the scrub over 48 hours ago an it is under 4% complete and FrontView is basically useless during this process. Keep in mind this is a RAID6 volume with 6TB drives, with a total volume size of about 16TB and it is running about 100 times slower than the data volume. This is a problem with the EDA500 and I am not sure why I was unable to get a response from mdgm-ntgr, StephenB or someone else within Netgear. I still have enough space on the 316 to rsync the data, AGAIN, and remove the eda1 volume to rebuild it, but it is a terrible solution. Netgear, please comment on this issue with a workaround or a solution to make the eda500 useful. It is unfortunate that I keep mostly inconsequential data on the eda's (yep I have 2 and regret both of them), because I do not trust either of them. The other thread I opened and got no response from is the following:
top - 00:28:48 up 180 days, 19:53, 1 user, load average: 7.23, 4.97, 4.90 Tasks: 278 total, 1 running, 277 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 3.5 sy, 0.0 ni, 2.3 id, 93.8 wa, 0.0 hi, 0.2 si, 0.0 st KiB Mem: 16298148 total, 15713032 used, 585116 free, 235312 buffers KiB Swap: 2094844 total, 4 used, 2094840 free. 13143588 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9332 root 20 0 0 0 0 S 8.3 0.0 637:58.07 md126_raid6 22272 root 39 19 0 0 0 D 4.0 0.0 91:25.11 md126_resync 20002 root 20 0 0 0 0 S 0.7 0.0 0:04.52 kworker/u8:10 3659 root 20 0 992516 8868 4920 S 0.3 0.1 831:17.00 leafp2p 3807 root 19 -1 2385380 105452 9828 S 0.3 0.6 272:46.17 readynasd 16698 snmp 20 0 73784 21028 3168 S 0.3 0.1 106:19.94 snmpd 17715 root 20 0 0 0 0 S 0.3 0.0 0:09.30 kworker/u8:0 20001 root 20 0 0 0 0 S 0.3 0.0 0:03.74 kworker/u8:9 22275 root 19 -1 32144 196 12 S 0.3 0.0 3:05.40 btrfs 22318 root 20 0 0 0 0 S 0.3 0.0 0:02.22 kworker/u8:1 31738 root 20 0 0 0 0 D 0.3 0.0 14:33.99 nfsd 1 root 20 0 202328 5312 3384 S 0.0 0.0 0:53.92 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:04.63 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 5:45.48 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 7 root 20 0 0 0 0 S 0.0 0.0 56:41.87 rcu_sched 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root rt 0 0 0 0 S 0.0 0.0 0:07.15 migration/0 10 root rt 0 0 0 0 S 0.0 0.0 0:41.41 watchdog/0 11 root rt 0 0 0 0 S 0.0 0.0 0:40.48 watchdog/1 12 root rt 0 0 0 0 S 0.0 0.0 0:07.94 migration/1 13 root 20 0 0 0 0 S 0.0 0.0 3:45.60 ksoftirqd/1 15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H 16 root rt 0 0 0 0 S 0.0 0.0 0:42.05 watchdog/2Notice over 93% wait and almost 0% CPU consumption. The resync process is still running and has been for over 62 hours and is currently at 3.5%.
I have no (0) installed applications and AntiVirus is disabled. In fact, after the factory reset a few months ago I have really done nothing with it.
I am willing to leave it running and provide logs and/or remote access for Netgear to troubleshoot and determine the cause. It seems this issue is now affecting more than just me.
And still no response from anyone at Netgear. If I run a scub on the volume on my EDA500 from SSH (btrfs scrub start /eda1), it runs 50X faster than if I run it from the GUI. That's comparable with the speed on the main array. Note that I am not using the -B option to not background the task. So what in the world is the GUI doing wrong when it starts a scrub, either scheduled or manually?
Scrubbing from the GUI involves more than just doing a scrub at the filesystem level.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
