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:
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.
Can you be more specific as to what it is doing if not just a BTRFS-level volume scrub? btrfs scrub status /eda1 returned data consistent with the progress bar in the GUI when I initiated the scrub via the GUI. In fact, the scrub I started with SSH also shows up in the GUI, progressing at the much accelerated pace. It's going a tad slower than the main volume -- I estimate it'll take about 18 to 20 hours -- but that's acceptable. The speed of the GUI-initiated scrub is not.
And even if it's doing something more, why does the scrub of my 14.5TB RDA500 volume take 54 days compared to 18 hours for my 27.3TB main volume? I assume that scrubbing the main volume is also doing that something more. Scrubbing the main volume uses about 50% of the CPU time -- enough to slow other processes some. Scrubbing the EDA500 via the GUI takes almost none. Scrubbing via SSH command takes about the same amount as the main volume scrub. Whatever causes that lack of CPU usage certainly seems like the probable root cause to me.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
