This dedup discussion (and my own bad expreience) have also left me with another grim thought: some time ago sparse-root zone support was ripped out of OpenSolaris.
Among the published rationales were transition to IPS and the assumption that most people used them to save on disk space (notion about saving RAM on shared objects was somehow dismissed). Regarding the disk savings, it was said that dedup would solve the problem, at least for those systems which use dedup on zoneroot dataset (and preferably that would be in the rpool, too). On one hand, storing zoneroots in the rpool was never practical for us because we tend to keep the rpool small and un-clobbered, and on the other hand, now adding dedup to rpool would seem like shooting oneself in the foot with a salt-loaded shotgun. Maybe it won't kill, but would hurt a lot and for a long time. On the third hand ;) with a small rpool hosting zoneroots as well, the DDT would reasonably be small too, and may actually boost performance while saving space. But lots of attention should now be paid to seperating /opt, parts of /var and stuff into delegated datasets from a larger datapool. And software like Sun JES which installs into a full-root zone's /usr might overwhelm a small rpool as well. Anyhow, Edward, is there a test for this scenario - i.e. a 10Gb pool with lots of non-unique data in small blocks? Thanks, //Jim _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
