From: Ross S. W. W. <RW...@me...> - 2012-12-12 17:12:30
|
Turbo Fredriksson [mailto:tu...@ba...] wrote: > On Dec 12, 2012, at 3:34 PM, Ross S. W. Walker wrote: > > > Dedup is slower than sparse files, but I don't think the issue the OP > > mentions has to do with duplicate data, but wasted space from thick > > allocation (unused data). > > > If you have cloned VMs though using ZFS cloned sparse zdevs could > > provide both performance and space savings. > > So sparse + dedup is a very nice combination that isn't available > (stable) in any other FS that I know of. There are storage solutions though from EMC, NetApp, Compellent and others that can provide sparse (thin provisioned) and deduplicated volumes through FC, iSCSI, FCoE and CIFS/NFS, so it isn't the only game in town. All VMware ESX VMDK files on top of NFS shares are thin, so if you use a ZFS deduplicated volume over NFS then it will be both thin and deduplicated by default. My personal best practice is to store VMDK files on NFS and put application data on RDMs using block storage protocols such as FC, iSCSI or FCoE. To that end ZFS is best for those NFS VMDK volumes of gigantic size. ZFS's self healing and data integrity checks are a life saver for those volumes that are too big to backup. Please note, that setup works for us because we have redundant virtual servers in multiple data centers with application data replicated and backed up in each data center. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. |