This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I know that question was asked at least one time before. But I did not find a suitable answer for that.
I started scrubbing my HDDs on May1st. Now, May 5th 51% are done. Thus itll be done in another five days.... Thats quite a while, I think.
Is there a way of speeding things up? Like priorization of that task(s) adding RAM or re run scrub more often?
Ok, I know the RN102 is not a very high performance NAS. Would speed (for that task improve when I repace it with a RN3xx? Actually I am happy with the 102...
Thanks in advance,
Chris
ps: Yes, the latest firmware is installed and one user in "online" plus one ISCASI connection is in use
It could be related to the quota, so if you can live without that try disabling it.
You can also clear the quota on the volume, not just the share. That will reduce the space information you see on the share page in the web ui.
The log you're looking at just reports the higher-level summary on the scrub - it doesn't show the two steps separately. I've never needed to see those details, so I don't know where they'd be logged. You could look in system.log and kernel.log.
If the performance is adequate then I suggest letting it run to completion.
A scrub takes about 40 hours on my RN526 with 4x6TB. It scales with raw disk size, so I'd estimate about 13 hours for 2x4TB. An RN100 series will of course be slower, but 10 days sounds high.
Did you download the log zip file, and look at the SMART stats? You can see them in volume.log.
" If the performance is adequate then I suggest letting it run to completion." I think, that's what I'll do.
"but 10 days sounds high." I agree. And I'd like to know, why it takes so long.
"Did you download the log zip file, and look at the SMART stats? You can see them in volume.log." Not yet. Are you talking about the attatched logfile you can access System--> logs ? Or do I have to access ReadyNas via SSH for that?
I reorganised all the task to one tast per month, starting on January 1st, Feb. First etc.
Nonethelesss I'd like to know, why the scrub took so long. Ok, while scrupping the ReadyNas was in use, what might have caused that slowdown.
I'd like an option like "run on every first saturday on January etc. This way such a task has "all the time needed" to complete without the dayly work...
Maybe download the logs and look at the smart stats (for instance in volume.log).
There are two different scrubs being run - one is the mdadm/RAID scrub, the second is the btrfs scrub. The btrfs scrub is a file system integrity check, so how long it takes is more variable than the mdadm scrub.
Do you have checksum or quota enabled on the volume settings wheel? Either could slow down the btrfs scrub.
"Maybe download the logs and look at the smart stats (for instance in volume.log)"
I did that and I am overwhelmed that there are so many logs.
Volume.log tells me, I have also a raid 0 ? AFAIK there I have a raid 1 ??
ReadyNAS did some scrubs earlier and it took less time. Here is some output:
"data disk test 2018-02-03 23:00:01 2018-02-04 06:58:17 pass data scrub 2018-02-04 21:00:02 2018-02-05 22:21:28 pass data scrub 2018-02-11 21:00:01 2018-02-12 23:39:50 pass data scrub 2018-02-18 21:00:02 2018-02-19 23:12:22 pass data defrag 2018-02-20 16:46:54 2018-02-20 18:16:24 completed data defrag 2018-03-01 00:00:02 2018-03-01 02:39:49 completed data scrub 2018-03-01 00:00:04 2018-03-02 05:57:02 pass data disk test 2018-03-08 00:00:02 2018-03-08 09:33:51 pass data balance 2018-03-15 00:00:01 2018-03-15 00:16:32 completed Done, had to relocate 0 out of 896 chunks Done, had to relocate data defrag 2018-04-01 00:00:01 2018-04-01 03:26:49 completed data scrub 2018-04-01 00:00:08 data disk test 2018-04-08 00:00:02 2018-04-08 08:12:13 pass data balance 2018-04-15 00:00:01 2018-04-15 00:07:25 completed Done, had to relocate 0 out of 1019 chunks Done, had to relocate data scrub 2018-05-01 00:00:02 2018-05-09 21:23:32 pass data defrag 2018-05-01 00:00:10 2018-05-01 06:36:24 completed
Where do I see whether ists madm/RAID or brtfs?
I have an ISCSI device with 100 GB, NTFS, Thin provisioning, auto- defrag and "never" as snapshot schedule. Sync writes is enabled.
Then there is a share "ASYS" with quota (64 GB) enabled. I could disable the quota as I don't see the advantage in it. This quota might actually be the "problem" because scrub was faster before I created that share.
Share "documents" has weekly smart snapshots enabled.
It could be related to the quota, so if you can live without that try disabling it.
You can also clear the quota on the volume, not just the share. That will reduce the space information you see on the share page in the web ui.
The log you're looking at just reports the higher-level summary on the scrub - it doesn't show the two steps separately. I've never needed to see those details, so I don't know where they'd be logged. You could look in system.log and kernel.log.
That leaves one question: Why use quota, when it slows down the system to such an extend?
Quota isn't just about storage limits, it also enables some BTRFS features that provide more info on where your space is going (how much in each share's snapshots, etc). So you do lose some useful info when you turn it off.
The slowdown is biggest on the RN100 series (which has the slowest processor and the least memory).
Maybe I'll get a 2xx or 3xx though I don't actually need a new one (but would like to have a new "toy").
You could do that, and repurpose your RN100 series as a backup NAS.
The 3xx isn't being produced anymore, so your options are RN21x or RN42x. If you are thinking about multigig ethernet in the future, the RN52x and RN62x both have 10GBase-T connections (though of course they are more expensive).
