[yast-devel] Transactional upgrades using the filesystem
We have some features open for rollbacks on upgrades. Give a look at this: "There is no ideal software, it always has bugs. Minor, major or security issues will always exist and modern operating systems need to deal with this fact. What if any software which user installs had a capability to rollback to previously known successful point and operation itself would take no time? What if developer or user has a tool which could checkpoint operating system and capability to revert changes in no time? This is possible if we will marry two great technologies: ZFS and Debian APT <http://www.nexenta.org/os/TransactionalZFSUpgrades>. Both technologies now part of Nexenta Operating System which is core foundation for its derivative distributions. Meet apt-clone <http://www.nexenta.org/os/AptCloneMan>. The tool which integrates with the NexentaCP system, keeps track of upgrade checkpoints and allows to create/destroy/edit checkpoints by request." http://osnews.com/story/19180/Transactional_Debian_Upgrades_with_ZFS_on_Nexe... -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 03-Feb-08, Duncan Mac-Vicar P. wrote:
We have some features open for rollbacks on upgrades. Give a look at this:
"There is no ideal software, it always has bugs. Minor, major or security issues will always exist and modern operating systems need to deal with this fact. What if any software which user installs had a capability to rollback to previously known successful point and operation itself would take no time? What if developer or user has a tool which could checkpoint operating system and capability to revert changes in no time? This is possible if we will marry two great technologies: ZFS and Debian APT <http://www.nexenta.org/os/TransactionalZFSUpgrades>. Both technologies now part of Nexenta Operating System which is core foundation for its derivative distributions. Meet apt-clone <http://www.nexenta.org/os/AptCloneMan>. The tool which integrates with the NexentaCP system, keeps track of upgrade checkpoints and allows to create/destroy/edit checkpoints by request."
http://osnews.com/story/19180/Transactional_Debian_Upgrades_with_ZFS_on_Nexe...
I do not see why ZFS would be required. AFAICS, only the snapshot functionality is required. This is available through LVM for any filesystem. If we are only required to be able to roll back the "software and system configuration" (rather than user data), this can be quite reliable. The number of applications that we have to control or at least be aware of to assure a consistent state of the data in the files, is relatively small (mainly rpm should not run while taking a snapshot). So, to be able to support this, we would require a snapshot functionality of the "system partition", which means LVM for the system partition ATM (ZFS support could be added later, if needed). Should we use LVM for this partition by default? (AFAICR we do not need to consider EVMS anymore...) -- Olaf Dabrunz (Olaf <at> dabrunz.com) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Mon, Feb 04, 2008 at 05:36:11PM +0100, Olaf Dabrunz wrote:
So, to be able to support this, we would require a snapshot functionality of the "system partition", which means LVM for the system partition ATM (ZFS support could be added later, if needed). Should we use LVM for this partition by default?
But /boot cannot reside on LVM and a rollback from a kernel update is likely a very much desired feature. ciao Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 04-Feb-08, Arvin Schnell wrote:
On Mon, Feb 04, 2008 at 05:36:11PM +0100, Olaf Dabrunz wrote:
So, to be able to support this, we would require a snapshot functionality of the "system partition", which means LVM for the system partition ATM (ZFS support could be added later, if needed). Should we use LVM for this partition by default?
But /boot cannot reside on LVM and a rollback from a kernel update is likely a very much desired feature.
Yes. No volume manager or file system offering snapshots (LVM, ZFS, ...) is (currently) supported by bootloaders. I do not know of any plans to support ZFS in a bootloader. Maintenance of bootloader code will be somewhat more work. LVM is a more generic choice here as well. Of course, we could fall back to using blocklists in the bootloader. But then this adds an undesirable point of failure, as these blocklists have to be kept up to date (whenever files necessary for booting are touched, by YaST, any other tool or the user). This was one important reason for moving to GRUB on x86. Maybe we can offer an interim solution where files in /boot are put into a snapshot (tar-)archive by YaST. When and if bootloaders support LVM, we could start using it in /boot as well. -- Olaf Dabrunz (Olaf <at> dabrunz.com) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (3)
-
Arvin Schnell -
Duncan Mac-Vicar P. -
Olaf Dabrunz