> Kyle McDonald wrote:
> > Tim Haley wrote:
> >> Ross wrote:
> >>   
> >>> While it's good that this is at least possible,
> that looks horribly complicated to me.  
> >>> Does anybody know if there's any work being done
> on making it easy to remove obsolete 
> >>> boot environments?
> >>>     
> >> If the clones were promoted at the time of their
> creation the BEs would 
> >> stay independent and individually deletable.
>  Promotes can fail, though, 
> > if there is not enough space.
> >>
> >> I was told a little while back when I ran into
> this myself on an Nevada 
> >> build where ludelete failed, that beadm *did*
> promote clones.  This 
> >> thread appears to be evidence to the contrary.  I
> think it's a bug, we 
> >> should either promote immediately on creation, or
> perhaps beadm destroy 
> >> could do the promotion behind the covers.

It is the beadm activate that will do this promotion it is not done at creation 
time. 
Also beadm destroy does promotes but in "reverse" so that the BE being 
destroyed becomes a leaf without any dependencies.

> >>   
> > If I understand this right, the latter option looks
> better to me. Why 
> > consume the disk space before you have to?
> > What does LU do?
> > 
> 
> ludelete doesn't handle this any better than beadm
> destroy does, it 
> fails for the same reasons. lucreate does not promote
> the clone it 
> creates when a new BE is spawned, either.

Are we saying that the currently active BE should not be the parent but that a 
newly spawned BE should be automatically promoted when it's created? As far as 
beadm is concerned the activated BE will always be the parent...

-evan
-- 
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to