casper@sun.com writes:
>>So is 5 with 1 hotswap (total 6) a sensible arrangement? And would
>>that leave me with something like 2tb (minus manufacturer exaggeration)
>>and one disk would be swallowed for parity data.
>
> Yeah, yeah. Perhaps you can ask the "SI" to change the definition of
> "
Greg Mason writes:
> Harry,
>
> ZFS will only compress data if it is able to gain more than 12% of
> space by compressing the data (I may be wrong on the exact
> percentage). If ZFS can't get get that 12% compression at least, it
> doesn't bother and will just store the block uncompressed.
>
> Al
OpenSolaris Forums writes:
> if you rsync data to zfs over existing files, you need to take
> something more into account:
>
> if you have a snapshot of your files and rsync the same files again,
> you need to use "--inplace" rsync option , otherwise completely new
> blocks will be allocated for
Jonathan writes:
> It appears I may have misread the initial post. I don't really know how
> I misread it, but I think I missed the snapshot portion of the message
> and got confused. I understand the interaction between snapshots,
> rsync, and --inplace being discussed now.
I don't think you
Thank you all for the information, I believe it is much clearer to me.
"Sequential Reads" should scale with the number of disks in the entire
zpool (regardless of amount of vdevs), and "Random Reads" will scale with
just the number of vdevs (aka idea I had before only applies to "Random
Reads"), wh
