Matthew Ahrens

@richardelling I'm not sure exactly what you mean by "ARC efficiency". All blocks are eligible to be in the ARC, regardless of `compress_arc_enabled`, though less may fit in the ARC...

> With compressed ARC, each compressed block consumes its lsize + (compressed) psize, for some period of time I think you're talking about the need to store the uncompressed version...

This was discussed at the Feb 26 OpenZFS meeting (link below), and the input was positive. So I think we should move forward with this proposal. @allanjude would you like...

@slw Compressed ARC should not have a huge performance impact compared to uncompressed ARC. It sounds like you have a workload where that is not the case. We would like...

`stride_dd` (included in the test suite) can be used instead of `dd ostride=`

My apologies, I didn't realize it isn't upstream yet, it's part of https://github.com/zfsonlinux/zfs/pull/7958. Probably easiest to wait for that to land.

Note: we (Delphix) are not planning to implement this, but I wanted to document the thinking we've done on the subject.

@HiFiPhile No. RAIDZ-N guarantees that any N disks can fail without data loss. Note that "split blocks" are a concept that is specific to device removal, which currently doesn't work...

Since you’re relying on the new vdev for redundancy, and you’re reading all the block pointers, you could not copy the parity. That way you don’t waste space for it,...

The zvol-vdev approach has a lot more space and performance overhead, compared to the indirect vdev. The most extreme example of this is turning frees into read-modify-writes (to zero out...