2011-07-15 11:10, phil.har...@gmail.com пишет:
If you clone zones from a golden image using ZFS cloning, you get fast, efficient dedup for free. Sparse root always was a horrible hack!
Sounds like a holy war is flaming up ;)
From what I heard, sparse root zones with shared common system libraries allowed to save not only on disk space but also on RAM. Can't vouch, never tested extensively myself. Cloning of golden zones is of course used in our systems. But this approach breaks badly upon any major systems update (i.e. LiveUpgrade to a new release) - many of the binaries change, and you either suddenly have the zones (wanting to) consume many gigabytes of disk space which are not there on a small rpool or a busy data pool, or you have to make a new golden image, clone a new set of zones and reinstall/migrate all applications and settings. True, this is a no-brainer for zones running a single task like an /opt/tomcat directory which can be tossed around to any OS, but becomes tedious for software with many packages and complicated settings, especially if (in some extremity) it was homebrewn and/or home-compiled and unpackaged ;) I am not the first (or probably last) to write about inconvenience of zone upgrades which loses the cloning benefit, and much of the same is true for upgrading cloned/deduped VM golden images as well, where the golden image is just some common baseline OS but the clones all run different software. And it is this different software which makes them useful and unique, and too distinct to maintain a dozen of golden images efficiently (i.e. there might be just 2 or 3 clones of each gold). But in general, the problem is there - you either accept that your OS images in effect won't be deduped, much or at all, after some lifespan involving OS upgrades, or you don't update them often (which may be inacceptable for security and/or paranoia types of deployments), or you use some trickery to update frequently and not lose much disk space, such as automation of software and configs migration from one clone (of old gold) to another clone (of new gold). Dedup was a promising variant in this context, unless it kills performance and/or stability... which was the subject of this thread, with Edward's research into performance of current dedup implementation (and perhaps some baseline to test whether real improvements appear in the future). And in terms of performance there's some surprise in Edward's findings regarding i.e. reads from the deduped data. For infrequent maintenance (i.e. monthly upgrades) zoneroots (OS image part) would be read-mostly and write performance of dedup may not matter much. If the updates must pour in often for whatever reason, then write and delete performance of dedup may begin to matter. Sorry about straying the discussion into zones - they, their performance and coping with changes introduced during lifetime (see OS upgrades), are one good example for discussion of dedup, and its one application which may be commonly useful on any server or workstation, not only on on hardware built for dedicated storage. Sparse-root vs. full-root zones, or disk images of VMs; are they stuffed in one rpool or spread between rpool and data pools - that detail is not actually the point of the thread. Actual useability of dedup for savings and gains on these tasks (preferably working also on low-mid-range boxes, where adding a good enterprise SSD would double the server cost - not only on those big good systems with tens of GB of RAM), and hopefully simplifying the system configuration and maintenance - that is indeed the point in question. //Jim _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
