On Wed, May 4, 2011 at 10:23 PM, Edward Ned Harvey < opensolarisisdeadlongliveopensola...@nedharvey.com> wrote:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > > boun...@opensolaris.org] On Behalf Of Ray Van Dolson > > > > Are any of you out there using dedupe ZFS file systems to store VMware > > VMDK (or any VM tech. really)? Curious what recordsize you use and > > what your hardware specs / experiences have been. > > Generally speaking, dedup doesn't work on VM images. (Same is true for ZFS > or netapp or anything else.) Because the VM images are all going to have > their own filesystems internally with whatever blocksize is relevant to the > guest OS. If the virtual blocks in the VM don't align with the ZFS (or > whatever FS) host blocks... Then even when you write duplicated data > inside > the guest, the host won't see it as a duplicated block. > > There are some situations where dedup may help on VM images... For example > if you're not using sparse files and you have a zero-filed disk... But in > that case, you should probably just use a sparse file instead... Or ... > If > you have a "golden" image that you're copying all over the place ... but in > that case, you should probably just use clones instead... > > Or if you're intimately familiar with both the guest & host filesystems, > and > you choose blocksizes carefully to make them align. But that seems > complicated and likely to fail. > > > That's patently false. VM images are the absolute best use-case for dedup outside of backup workloads. I'm not sure who told you/where you got the idea that VM images are not ripe for dedup, but it's wrong. --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
