On 5/4/2011 5:11 PM, Brandon High wrote:
On Wed, May 4, 2011 at 4:36 PM, Erik Trimble<erik.trim...@oracle.com> wrote:
If so, I'm almost certain NetApp is doing post-write dedup. That way, the
strictly controlled max FlexVol size helps with keeping the resource limits
down, as it will be able to round-robin the post-write dedup to each FlexVol
in turn.
They are, its in their docs. A volume is dedup'd when 20% of
non-deduped data is added to it, or something similar. 8 volumes can
be processed at once though, I believe, and it could be that weaker
systems are not able to do as many in parallel.
Sounds rational.
block usage has a significant 4k presence. One way I reduced this initally
was to have the VMdisk image stored on local disk, then copied the *entire*
image to the ZFS server, so the server saw a single large file, which meant
it tended to write full 128k blocks. Do note, that my 30 images only takes
Wouldn't you have been better off cloning datasets that contain an
unconfigured install and customizing from there?
-B
Given that my "OS" installs include a fair amount of 3rd-party add-ons
(compilers, SDKs, et al), I generally find the best method for me is to
fully configure a client (with the VMdisk on local storage), then copy
that VMdisk to the ZFS server as a "golden image". I can then clone
that image for my other clients of that type, and only have to change
the network information.
Initially, each new VM image consumes about 1MB of space. :-)
Overall, I've found that as I have to patch each image, it's worth-while
to take a new "golden-image" snapshot every so often, and then
reconfigure each client machine again from that new Golden image. I'm
sure I could do some optimization here, but the method works well enough.
What you want to avoid is having the OS image written to, and waiting
for any other configuration and customization to happen AFTER it was
placed on the ZFS server is sub-optimal.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
