Bart Smaalders wrote:
> Sarah Jelinek wrote:
>> James Carlson wrote:
>>> Moinak Ghosh writes:
>>>  
>>>>    Disk space might be cheap, but enough software and data bloat is 
>>>> present
>>>>    and growing today to gobble up whatever space you can throw at 
>>>> it. IMHO
>>>>    not supporting in-place upgrade will hit workstation users hard. 
>>>> Most of the
>>>>    disk space available will be partitioned off for various stuff 
>>>> and there will
>>>>    be multiboot configurations.
>>>>     
>>>
>>> Note that Live Upgrade is generally used for the operating system
>>> itself.  There's no reason to allocate space in the BE for user data
>>> and other things that LU doesn't address, and you don't have to use it
>>> for applications if you don't want to.  (I've yet to meet the
>>> application that understands how to upgrade a mounted ABE anyway.)
>>>
>>>  
>>>> It will be a pain to allocate space for liveupgrade.
>>>>    A short downtime is not a factor in this scenario.
>>>>
>>>>    -> 2. There is no rollback mechanism, short of a full restore, 
>>>> if something gets broken.
>>>>
>>>>    ZFS root should help here.
>>>>     
>>>
>>> ZFS root should be the future of live upgrade.
>>>
>>>   
>> ZFS root is the future of live upgrade in Caiman. It will take 
>> seconds to do a live upgrade, using the ZFS snapshot and clone 
>> capabilities.
>>
>
>
> We should therefore require ZFS root for Solaris Nevada, and arrange
> for separation of user data from system data, either by refactoring
> filesystem layouts or using a translucent filesystem.  In either
> case, it should be possible to snapshot, clone, and patch/upgrade
> the systems's filesystem(s) (today / and /usr) w/o affecting mail
> messages, log files, etc.
Our plan is to require ZFS root for Solaris Nevada, well at least 
require that Caiman only supports ZFS root. The separation of user data 
from system data is an important aspect of this and one that needs some 
work.

I agree that we should be able to snapshot, clone and patch/upgrade the 
systems filesystems without affecting the user data you mention.

sarah
****
>
> - Bart
>
>
>
>


Reply via email to