Hi, I got a message from you off-list that doesn't show up in the thread even after hours. As you mentioned the aspect here as well I'd like to respond to, I'll do it from here:
> Third, as for ZFS scrub prioritization, Richard > answered your question about that. He said it is > low priority and can be tuned lower. However, he was > answering within the <br>context of an 11 disk RAIDZ2 > with slow disks His exact words were: > > > This could be tuned lower, but your storage > is slow and *any* I/O activity will be > noticed. Richard told us two times that scrub already is as low in priority as can be. From another message: "Scrub is already the lowest priority. Would you like it to be lower?" ============================================================================= As much as the comparison goes between "slow" and "fast" storage. I have understood that Richard's message was that with storage providing better random I/O zfs priority scheduling will perform significantly better, providing less degradation of concurrent load. While I am even inclined to buy that, nobody will be able to tell me how a certain system will behave until it was tested, and to what degree concurrent scrubbing still will be possible. Another thing: people are talking a lot about narrow vdevs and mirrors. However, when you need to build a 200 TB pool you end up with a lot of disks in the first place. You will need at least double failover resilience for such a pool. If one would do that with mirrors, ending up with app. 600 TB gross to provide 200 TB net capacity is definitely NOT an option. Regards, Tonmaus -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
