ive got an array of 3 drives, nothing fancy but 32tb. I think ive got about 15tb of actual data, mostly video. I started a scrub on may 29 and its not done yet. says it will finish on june 10. that seems insane to me. speed is 16MB/s. the drives are not slow, I tested the speed on this system with nothing changed and it was around 275MB/s. granted this is not a straight read or write, but seriously? 12 days?
2.28tb of data was scrubbed in 1 hour and 40 minutes, 411MiB/s, raid1.
@jihiggs Hello again.
Re:
This is entirely possible. But it very much varies with the btrfs-raid level in play and obviously the hardware speeds involved. Can you give more details about the Rockstor version you are running on - more specifically in this case the kernel version used. There have been many speed-ups of late in btrfs but the parity raid levels are know to still have significant speed issues on occasions.
Kernel version visible in top-right of Web-UI, or via command line if preferred via:
uname -a
Hope that helps, at least for some context.
1 Like
raid 5, 4.5.9-1. I know raid 5 is kinda iffy with btrfs, but other than slow scrubs its working fine. I do get a repeating message in my terminal "BTRFS info (device sdc): qgroup scan completed (inconsistency flag cleared). not sure what that means. unfortunately the scrub did not finish as I had to reboot.
@jihiggs Re
Given you are now on 4.5.9-1 you could consider moving to a mixed raid profile:
BUT ONLY IF YOU ARE ALREADY ON A “BUILT ON openSUSE” LEAP 15.4 BASE.
Or Tumbleweed of course.
But if you are still on a Leap 15.3 base then take a look at our in-place update HowTo:
https://rockstor.com/docs/howtos/15-3_to_15-4.html
or the similar earlier howto first if you are still on a 15.2 base, if you are that far back. Mixed raid doesn’t need kernel backports when on 15.4.
Testing Changelog reference for when mixed raid levels were added in Rockstor:
But you might as well be on 4.6.0-0 which is available in testing from 9 days ago. See later on in the above referenced forum thread.
So given metadata is likely the main slow-down on the parity raid side, you could consider doing a Resize/ReRaid on that pool:
to say “raid5-1”: our nomenclature for data = brtrfs-raid5 with metadata btrfs-raid1:
And once the associated balance has finished (again could still take quite some time) the result should be reflected in the Pool details here:
Obviously this is a non trivial modification of live data, so refresh back-up before hand.
But as you likely already know the system can be used, mostly as normal, during this operation. There will of course be some drive subsystem bandwidth and CPU busied by the event.
Yes, no worries there. Just info after a qgroup rescan.
You can always start it off again.
Hope that helps.
2 Likes
I was at one time running on both RAID 5 and RAID 6, and also observed very very long scrub times.
It would take days on end. Where the disk were constantly hit hard. I have therefore switched to RAID1.
Since then I have waited to see if the day would come where btrfs would be optimized to scrub faster on RAID56. It doesn’t seem to have happened. Allthough I have seen mentions that it should be doable.
The mixed RAID profiles was on my wishlist for Rockstor, and I’m happy to see it made available.
I’ll probably experiment with it on a test system at one time, so see how it performs.
But i suspect that scrubs will still be slow as the majority of data would still be RAID56. But the mixed profile should protect better from some of the vulnerabillties that still exist in the RAID56 implementation.
3 Likes