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
signature.asc
Description: Digital signature
