Unluckily, I didn't notice if the true origin was transformed into a clone after promoting the false origin. So, my mistake, I destroyed the false origin recursively, luckily after promoting the other clones, so, I just ended up destroying the true origin.....not a problem, just a template. That happened only because the true origin was a template zone, not running, thus not seen as "used" by my destroy....while the other running zones complained when I was mistakenly destroying something that would have destroyed their zbe! :) lucky :) I've lost my "clone" features, so all my derived fss, are now occupying space for what is actually the same bytes....but, so far, they're not as many... Anyway, I think there should be something else than "promote" (I've been looking for it before promoting...), such as "freefromorigin", or "makeitfull", or "nomoredependency", or "justme"...or... :) That would be useful. Doing send/recv it's just a trick you can't always do, because for a moment you have to double the used space, until you have set. Actually, maybe the problem is right before: I ended up here while moving the cloned fs over another pool. Why send/recv complains of a missing clone at destination? Why not an option to send the fs together with the origin data? That's what I'm looking for at destination... Gabriele. ---------------------------------------------------------------------------------- Da: Jim Klimov A: [email protected] Data: 21 gennaio 2013 16.33.30 CET Oggetto: Re: [discuss] zfs clones/origins On 2013-01-21 14:18, Gabriele Bulfon wrote: Hi, while playing with a cloned structure, I found myself in an unwanted dependency of snaps/fs. At the beginning there was a template fs (xsbase), from which I cloned 3 fs/zones. Doesn't it work to promote xsbase again? Then it should become the common origin. I did have a similar problem, where the clones and origins had some commonly-named snapshots (i.e. the whole hierarchy root for zones was recursively snapshotted). This did cause my promotions to fail, so I had to rename the "true origin's" snapshot, and for that I had to stop all zones (for some reason, such renamings cause remount of the descendant filesystems - and they say "Device busy" if the zones are running). After scheduling a downtime and doing the "zfs rename" and "zfs promote" actions, I ended up being able to demote and destroy the false origin. Not much further than last night, and it bugged us for months on a busy zone server ;) So I had to play promoting of the other clones, to free the unneeded fs and destroy it. Now I have a cross dependency of the zones I can't get rid of... Is there any way to get rid of the "origin", by telling the fs to fork and be indEpendent??? Short of zfs send or rsync? I don't think there are currently many other ways.. //Jim ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175541-02f10c6f Modify Your Subscription: https://www.listbox.com/member/?&id;secret=21175541-29e3e0ee Powered by Listbox: http://www.listbox.com
------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
