Protected: If Scrubs Hurt, Your ZFS Design Is Broken

  • Thread starter Thread starter Allan Jude
  • Start date Start date
There are at four typos in the first block (if anyone reading this can fix them):

ZFS scrub performance shouldn’t come at the expense of production worklaods. If scrubs cause latency or downtime, your pool lacks the IOPs and metadata performance needed for healthy maintanance. Learn why scrub performance suffers, how pool design contributres to the problem, and how metadata offload with sepcial VDEVs can improve both scrub and resilver performance.
 
So, ZFS may not require more resources than on average while scrubbing or there's something wrong with it? I think it must cause a reduction of filesystem availability and a small CPU load.
 
Espionage724 said:
It seems viewable now :D
Click to expand...
That's great news! Thank you for letting us know :)
I like Klara's articles, they aren't always for my usage but when they are there is always useful information.

MG said:
So, ZFS may not require more resources than on average while scrubbing or there's something wrong with it? I think it must cause a reduction of filesystem availability and a small CPU load.
Click to expand...
Hmm that's not what I've understood, for me it seems the impact essentially depends on few factors: layout, hardware(CPU/DISK/RAM) and what type of applications are running at the same time.
If one of the condition is filled then slowness can be expected, and if several conditions are met then the slowness is bigger.
That's my own interpretation and I can be totally wrong though.
 
The article was genuinely helpful. I didn't appreciate that zdb -bb <pool> was available to break down allocated space by block type. But it still seems to me that the initial sizing of a special VDEV is something a black art, since getting Metadata Total size from zdb can only be done after the pool is populated. [Better late than never...]
 
You must log in or register to reply here.
Back
Top