On Tue, Oct 04, 2011 at 09:28:36PM -0700, Richard Elling wrote:
On Oct 4, 2011, at 4:14 PM, Daniel Carosone wrote:
I sent it twice, because something strange happened on the first send,
to the ashift=12 pool. zfs list -o space showed figures at least
twice those on the source, maybe
On Sat, 8 Oct 2011, Daniel Carosone wrote:
This isn't about whether the metadata compresses, this is about
whether ZFS is smart enough to use all the space in a 4k block for
metadata, rather than assuming it can fit at best 512 bytes,
regardless of ashift. By packing, I meant packing them full
2011-10-08 7:25, Daniel Carosone пишет:
On Tue, Oct 04, 2011 at 09:28:36PM -0700, Richard Elling wrote:
On Oct 4, 2011, at 4:14 PM, Daniel Carosone wrote:
What is going on? Is there really that much metadata overhead? How
many metadata blocks are needed for each 8k vol block, and are they
On Mon, 10 Oct 2011, Jim Klimov wrote:
Thus I proposed the second idea with a code-only solution
to optimize performance (force user-configured minimal
data block sizes and physical alignments) where metadata
blocks would remain 512 bytes because the pool is formally
ashift=9 - and on-disk data
[exposed organs below…]
On Oct 7, 2011, at 8:25 PM, Daniel Carosone wrote:
On Tue, Oct 04, 2011 at 09:28:36PM -0700, Richard Elling wrote:
On Oct 4, 2011, at 4:14 PM, Daniel Carosone wrote:
I sent it twice, because something strange happened on the first send,
to the ashift=12 pool. zfs
On Oct 4, 2011, at 4:14 PM, Daniel Carosone wrote:
I sent a zvol from host a, to host b, twice. Host b has two pools,
one ashift=9, one ashift=12. I sent the zvol to each of the pools on
b. The original source pool is ashift=9, and an old revision (2009_06
because it's still running xen).
