NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
A very LONG scrub
I manually kicked off my first scrub about four hours ago. I'm running 4x4TB WDC Reds @ 5400 RPM on RAID6, resulting in a 7.27TB volume. These are my present stats, calculated in Excel: % ...
The scrub will speed up a bit once the filesystem portion of the scrub finishes. But it'll never be "fast" using RAID6 on a RN104. RAID5 can offload some parity calculation work to a specialized engine on the CPU, but no such engine exists for RAID6 on the RN104 CPU, and RAID6 is much more computationally intensive than RAID5. You'd probably have a better experience using RAID10 on RN104.
> Are you using bit-rot protection?
Yes.
Thanks,
Jeff Bowman
Fairbanks, Alaska
Looks like you have quite a bit of fragmentation from this and that is probably what is slowing down the scrub.
We link enabling/disabling bit-rot protection to enabling/disabling CoW but they are two separate things. With CoW each time you make a write the existing data is not overwritten. With a lot of in place modifications to files you will get a lot of fragmentation and this will lead to longer scrubs.
Also WD RED drives are 5400RPM drives so the performance will be slower than with 7200 RPM disks.
Yes... I would like to have purchased the Pro drives instead, but as always cost is an issue. I just didn't expect this.
So it sounds like I should defrag first, then. Do you agree?
Here's my current schedule:
Scrub: 1/1;4/1;7/1;10/1
Defrag: 2/1;5/1;8/1;11/1
Balance: 3/1;6/1;9/1;12/1
Test: Day 2 of every month
What would you recommend? Also: will it be safe to simply cancel the current scrub, should I determine to alter the order of these?
Thanks,
Jeff Bowman
Fairbanks, AlaskaThe scrub will speed up a bit once the filesystem portion of the scrub finishes. But it'll never be "fast" using RAID6 on a RN104. RAID5 can offload some parity calculation work to a specialized engine on the CPU, but no such engine exists for RAID6 on the RN104 CPU, and RAID6 is much more computationally intensive than RAID5. You'd probably have a better experience using RAID10 on RN104.
> no such engine exists for RAID6 on the RN104 CPU
What about the RN204?
Also, do you have any suggestion for my prior question, re: order of actions?
Thanks,
Jeff Bowman
Fairbanks, Alaska
InteXX wrote:
So it sounds like I should defrag first, then. Do you agree?
I don't think it really matters, especially with the month gaps. If you are manually deleting snapshots, then it'd be good to do that shortly before the defrag is done (since that minimizes the space used by snapshots).
I'd just stick with your schedule. Though perhaps shift the disk test to the middle of the month, just to make sure it doesn't overlap with the other maintenance.
> I'd just stick with your schedule
OK, sounds good. (FYI I'm not taking snapshots.)
Two months, though—my, my... a lot could happen in that time. Power outage, have to restart, etc.
I'm kinda leaning toward mdgm's suggestion that fragmentation might be behind this. This is my very first volume maintenance operation, after all.
Were you me, would you cancel the scrub and run a defrag first? The current volume has been up about six months with many file overwrites, deletions, etc. during that time.
The current stats:
% Complete 1.33% Start 3/8/2016 15:44:03 Current 3/9/2016 12:52:05 Duration 1589:00:24 Completion 5/14/2016 17:52:29
Thanks,
Jeff Bowman
Fairbanks, Alaska> The defrag should run more quickly
It's running much more quickly now, thank you.
Thanks,
Jeff Bowman
Fairbanks, Alaska
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
