From: Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
Performance is much better if you use mirrors instead of raid. (Sequential
performance is just as good either way, but sequential IO is unusual for most
use cases. Random IO is much better with mirrors, and that includes scrubs
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Fajar A. Nugraha
So my
suggestion is actually just present one huge 25TB LUN to zfs and let
the SAN handle redundancy.
Oh - No
Definitely let zfs handle the redundancy. Because ZFS is
On 10/26/2012 04:29 AM, Karl Wagner wrote:
Does it not store a separate checksum for a parity block? If so, it
should not even need to recalculate the parity: assuming checksums
match for all data and parity blocks, the data is good.
I could understand why it would not store a checksum for a
On 27/10/12 11:56 AM, Ray Arachelian wrote:
On 10/26/2012 04:29 AM, Karl Wagner wrote:
Does it not store a separate checksum for a parity block? If so, it
should not even need to recalculate the parity: assuming checksums
match for all data and parity blocks, the data is good.
...
Parity is
2012-10-27 20:54, Toby Thain wrote:
Parity is very simple to calculate and doesn't use a lot of CPU - just
slightly more work than reading all the blocks: read all the stripe
blocks on all the drives involved in a stripe, then do a simple XOR
operation across all the data. The actual checksums
On Sat, Oct 27, 2012 at 9:21 AM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris)
opensolarisisdeadlongliveopensola...@nedharvey.com wrote:
From: Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
Performance is much better if you use mirrors instead of raid.
(Sequential
On Sat, Oct 27, 2012 at 12:35 PM, Jim Klimov jimkli...@cos.ru wrote:
2012-10-27 20:54, Toby Thain wrote:
Parity is very simple to calculate and doesn't use a lot of CPU - just
slightly more work than reading all the blocks: read all the stripe
blocks on all the drives involved in a stripe,
