> Are you sure that you didn't also enable > something which > does consume lots of CPU such as enabling some sort > of compression, > sha256 checksums, or deduplication?
None of them is active on that pool or in any existing file system. Maybe the issue is particular to RAIDZ2, which is comparably recent. On that occasion: does anybody know if ZFS reads all parities during a scrub? Wouldn't it be sufficient for stale corruption detection to read only one parity set unless an error occurs there? > The main concern that one should have is I/O > bandwidth rather than CPU > consumption since "software" based RAID must handle > the work using the > system's CPU rather than expecting it to be done by > some other CPU. > There are more I/Os and (in the case of mirroring) > more data > transferred. What I am trying to say is that CPU may become the bottleneck for I/O in case of parity-secured stripe sets. Mirrors and simple stripe sets have almost 0 impact on CPU. So far at least my observations. Moreover, x86 processors not optimized for that kind of work as much as i.e. an Areca controller with a dedicated XOR chip is, in its targeted field. Regards, Tonmaus -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
