Alexander E. Patrakov wrote: > A technology exists that can keep downtime to a minimum. It is called > "btrfs snapshots", see below for the details. After Wheezy, Debian > should support it natively in installer, dpkg and apt/aptitude. That is a rather complicated solution. It has very significant problems, including: What if a change is made to the current /etc or other part of the filesystem while the upgrade is proceeding in a snapshot? You then have the problem of needing to merge changes between versions of the filesystem, and the possibility of conflicts. While it might work for some, there's a much simpler way to minimize daemon downtime: Avoid stopping a daemon in the prerm, and instead restart it in the postinst. Downtime then becomes < 1 second per daemon (less than a kexec reboot). Any package can easily be converted to do this. In debian/rules: override_dh_installinit: dh_installinit --restart-after-upgrade However, the daemon then needs to be audited to ensure that it will continue to work while its foundation is being upgraded underneath it. For many daemons that don't use a great deal of packaged files after startup, it's easy for a maintainer familiar with the daemon to show this is the case. Others may need to build a hardlink tree of files on startup (goes well with chrooting..) to avoid problems. I count 43 packages using this or similar techniques. This includes important ones like bind9. Making --restart-after-upgrade the default is perennially on my TODO list for consideration at the next debhelper compatability level. Making that change would require a lot of work by maintainers to do the audits or disable it, but it still might happen. -- see shy jo
Attachment:
signature.asc
Description: Digital signature