[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#679853: marked as done (general: Too much downtime during a big dist-upgrade - avoidable with snapshots)

Your message dated Mon, 24 Sep 2012 16:25:41 +0200
with message-id <201209241625.42568.holger@layer-acht.org>
and subject line too broad idea / complain
has caused the Debian Bug report #679853,
regarding general: Too much downtime during a big dist-upgrade - avoidable with snapshots
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
679853: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679853
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: general, apt
Severity: normal

Today I ran "aptitude update ; aptitude dist-upgrade" on my virtual
machine that provides some web applications to the clients. There were
126 updated packages (accumulated since 2012-06-18). The upgrade and
the following kexec-based reboot went well, except for one thing: it
took too long between stopping and starting again apache and mysql.

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.

1) The installer should be able to install the system to a btrfs
subvolume (except /home and /var, which should be on separate
subvolumes).

2) On such system, dpkg and apt/aptitude, if requested by the user
and/or by default, should make a writeable snapshot of the root
subvolume, mount it to some temporary location, chroot into it and
perform the upgrade there. During this process, the main system will,
of course, continue to work.

3) Then a kexec-based reboot should happen, using the new subvolume as
the root filesystem.

A kexec-based reboot is currently faster than a two-week dist-upgrade
of the testing distribution, and thus it should be good for minimizing
the downtime. Besides, the kernel is upgraded often in the testing
distribution, thus a reboot is needed anyway.

Maybe this procedure is also doable with LVM snapshots.

Also note that this is different from the "offline updates" proposal
from Lennart Poettering (that essentially involves running the current
dist-upgrade between two reboots) and has different goals. His goal is
to ensure consistency during and after the upgrade, my goal is to
minimize downtime.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Alexander E. Patrakov

--- End Message ---
--- Begin Message --- 
Hi,

closing this bug report as the idea is too broad to be usefully tracked 
here... please file bugs about the individual components, if at all.


cheers,
	Holger

--- End Message ---
Reply to: