On Sat, Dec 19, 2009 at 8:34 AM, Colin Raven <co...@clearcutnetworks.com> wrote: > If snapshots reside within the confines of the pool, are you saying that > dedup will also count what's contained inside the snapshots? I'm not sure > why, but that thought is vaguely disturbing on some level.
Sure, why not? Let's say you have snapshots enabled on a dataset with 1TB of files in it, and then decide to move 500GB to a new dataset for other sharing options, or what have you. If dedup didn't count the snapshots you'd wind up with 500GB in your original live dataset, an additional 500GB in the snapshots, and an additional 500GB in the new dataset. For instance, tank/export/samba/backups used to be a directory in tank/export/samba/public. Snapshots being used in dedup saved me 700+GB. tank/export/samba/backups 704G 3.35T 704G /export/samba/backups tank/export/samba/public 816G 3.35T 101G /export/samba/public > in fact handy. Hourly...ummm, maybe the same - but Daily/Monthly should > reside "elsewhere". That's what replication to another system via send/recv is for. See backups, DR. > Y'know, that is a GREAT point. Taking this one step further then - does that > also imply that there's one "hot spot" physically on a disk that keeps > getting read/written to? if so then your point has even greater merit for > more reasons...disk wear for starters, and other stuff too, no doubt. I believe I read that there is a max ref count for blocks, and beyond that the data is written out once again. This is for resilience and to avoid hot spots. -B -- Brandon High : bh...@freaks.com Indecision is the key to flexibility. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
