I was expecting zfs send tank/export/projects/project1...@today would send everything up to @today. That is the only snapshot and I am not using the -i options. The things worries me is that tank/export/projects/project1_nb was the first file system that I tested with full dedup and compression. and the first ~300GB usage (before I merged the other file systems) showing ~2.5x dedup ratio. so the data should be easily more than 600 GB. My initial worry was the migration pool won't even have enough space to receive the file system when I started but the turn out to be very unexpected result. My question is where is the dedupped data went if the new pool is showing 1.0x dedup ratio and the old pool is show a 2.53 ratio yet both take up about the same size ~400GB.
Is the -R option required for what I am trying to do? what I am try to do is to un-dedup the file system. I actually preferred if non of the properties was replicated. This is quite confusing and I won't be a surprise if other people are taking an incomplete backup with zfs send if that's the case. I will redo the send again with -R and see what happens. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
