comment below... On Jan 28, 2011, at 7:13 AM, Ware Adams wrote:
> There's a lot of discussion of dedup performance issues (including problems > backing out of using it which concerns me), but many/most of those involve > relatively limited RAM and CPU configurations. I wanted to see if there is > experience that people could share using it on with higher RAM levels and > l2arc. > > We have built a backup storage server nearly identical to this: > > http://www.natecarlson.com/2010/05/07/review-supermicros-sc847a-4u-chassis-with-36-drive-bays/ > > briefly: > > SuperMicro 36 bay case > 48 GB RAM > 2x 5620 CPU > Hitachi A7K2000 drives for storage > X25-M for l2arc (160 GB) > 4x LSI SAS9211-8i > Solaris 11 Express > > The main storage pool is mirrored and uses gzip compression. Our use > consists of backing up daily snapshots of multiple MySQL hosts from a Sun > 7410 appliance. We rsync the snapshot to the backup server (ZFS send to > non-appliance host isn't supported on the 7000 unfortunately), snapshot (so > now we have a snapshot of that matches the original on the 7410), clone, > start MySQL on the clone to verify the backup, shut down MySQL. We do this > daily across 10 hosts which have significant overlap in data. > > I might guess that dedup would provide good space savings, but before I turn > it on I wanted to see if people with larger configurations had found it > workable. My greatest concern are stories of not only poor performance but > worse complete non-responsiveness when trying to zfs destroy a filesystem > with dedup turned on. > > We are somewhat flexible here. We are not terribly pressed for space, and we > do not need massive performance out of this. Because of that I probably > won't use dedup without hearing it is workable on a similar configuration, > but if people have had success it would give us more cushion for inevitable > data growth. I apologize for the shortness, but since you have such large, slow drives, rather than making a single huge pool and deduping, create a pool per month/week/quarter. Send the snaps over that you need, destroy the old pool. KISS & fast destroy. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
