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. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
