Hi Eric, > 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 > ystems, there are tradeoffs.
I think we all may agree that the topic here is scrub trade-offs, specifically. My question is if manageability of the pool, and that includes periodical scrubs, is a trade-off as well. It would be very bad news, if it were. Maintenance functions should be practicable on any supported configuration, if possible. > 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. The priority balance only works as long as the IO is within ZFS. As soon as the request is in the pipe of the controller/disk, no further bias will occur, as that subsystem is agnostic to ZFS rules. This is where Richards answer, just above if you read this from jive, kicks in. This leads to the pool being basically not operational from a production POV during scrub pass. From that perspective, any scrub pass exceeding a periodically acceptable service window is "too long". In such a situation, a "pause" option for resuming scrub passes upon the next service window might help. The advantage: such an option would be usable on any hardware. Regards, Tonmaus -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
