Sarah Jelinek wrote: > Hi Ethan, > > My comments inline.. > > >>>> -Who manages the retention policies? libbe? The text says that libbe >>>> will provide a way to delete, display, create snapshots, but if a >>>> policy indicates a retention of say 5 hours, who goes back and >>>> deletes this? In >> libbe enforces the retention policy, but its more of a "passive" >> enforcement. i.e. we won't be having a be-daemon running around >> checking statuses of BE snapshots. Instead, on each invocation of >> BE or BE snapshot creation, we run through the snapshots and delete >> the ones that have outstayed their policy. >> > Ah, ok, I see. I assume users can create agents to handle this policy > management more actively if they wanted?
We didn't plan on providing any public interfaces to do this. If its something we do need to do actively, I'd rather the BE system handle inherently. > >>>> 3.1.1.3 you indicate that the persistence policy must be managed by >>>> caller. But, you also indicate a 'default' policy that somehow gets >>>> enforced by libbe? It might be good to outline exactly what libbe >>>> will do, say in the case of a default policy, and what it will or >>>> won't do in other cases. >> Hopefully this is answered in the description above. >> > Sort of.. .I can see that libbe will do what it can when invoked. But, > the persistence policy is something libbe looks like it will be handling > as well, even if only passively? I think we need to clarify 3.1.1.3 a little bit. What's described as the persistent snapshot class is really no different from the the "infinity" class I described in my previous mail. >>>> -How will synclist datasets be represented in the namespace? Based >>>> on your design it is assumed that non BE datasets will be under the >>>> root pool which they belong, and not in the BE namespace. But, if a >>>> user wants to have datasets not share, how will this be managed? >> All non-shared datasets the user wishes to create for a BE needs to >> be under the BE root dataset. These can't be kept in sync. >> I'm not sure what you mean by a synclist dataset. If some piece of >> data needs to be kept the same across all BE, why keep it in >> non-shared space? > Ok.. so, any non-root, and non-shared datasets are in the BE namespace, > and when doing an snap create those datasets will not be copied to the > new BE? If they are under the BE root dataset, they will get cloned. > > You wouldn't keep data that needs to be the same across all BE's in the > non-shared space. I was asking what the namespace looks like for > datasets that they don't want to share. It sounds as if they will be in > the BE namespace and won't be copied if they are non-root datasets(/, > /var, /opt...). Is this correct? No, every dataset underneath the BE's root dataset will get cloned when creating a new BE. For example, if BE1 has: rpool/ROOT/BE1 rpool/ROOT/BE1/opt rpool/ROOT/BE1/zones BE2 will get cloned datasets from all of the above: rpool/ROOT/BE2 rpool/ROOT/BE2/opt rpool/ROOT/BE2/zones -ethan > > thanks, > sarah > **** >> >> Thanks, >> -ethan >> > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
