On Wed, Apr 28 at 1:34, Tonmaus wrote:
Zfs scrub needs to access all written data on all
disks and is usually
disk-seek or disk I/O bound so it is difficult to
keep it from hogging
the disk resources. A pool based on mirror devices
will behave much
more nicely while being scrubbed than one based on
RAIDz2.
Experience seconded entirely. I'd like to repeat that I think we
need more efficient load balancing functions in order to keep
housekeeping payload manageable. Detrimental side effects of scrub
should not be a decision point for choosing certain hardware or
redundancy concepts in my opinion.
While there may be some possible optimizations, i'm sure everyone
would love the random performance of mirror vdevs, combined with the
redundancy of raidz3 and the space of a raidz1. However, as in all
systems, there are tradeoffs.
To scrub a long lived, full pool, you must read essentially every
sector on every component device, and if you're going to do it in the
order in which your transactions occurred, it'll wind up devolving to
random IO eventually.
You can choose to bias your workloads so that foreground IO takes
priority over scrub, but then you've got the cases where people
complain that their scrub takes too long. There may be knobs for
individuals to use, but I don't think overall there's a magic answer.
--eric
--
Eric D. Mudama
edmud...@mail.bounceswoosh.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
