delay when upgrading

[Jamie Strandboge]

When trying to perform an upgrade (bug #1447652), I noticed a significant delay before seeing any progress. From IRC:

08:16 < mvo> jdstrand: I think its because there is a thing called SyncBootloader files that will always cp /boot/a -> /boot/b which
is now very slow because we use sync and also not needed because ubuntu-device-flash already did that
08:17 < mvo> jdstrand: so its a separate bug, but if you don't mind, please file it because I think we need to kill that function
08:17 < mvo> jdstrand: if you ctrl-z and ps afx you probably see a "cp -a" there
08:17 < mvo> cp -a /boot/a /boot/b
08:17 < mvo> to be precise

[Michael Vogt (mvo)]

I think we just need to remove SyncBootloaderFiles as ubuntu-device-flash is populating both /boot/a and /boot/b nowdays.

[Michael Vogt (mvo)]

Fwiw, I did a stop-watch test how long the copy takes on a current snappy BBB system with my SD card and it takes ~7:30min(!) for the "cp -a".

[Steve Langasek (vorlon)]

On Mon, Apr 27, 2015 at 01:20:35PM -0000, Michael Vogt wrote:
> I think we just need to remove SyncBootloaderFiles as ubuntu-device-
> flash is populating both /boot/a and /boot/b nowdays.

I thought that one of the reasons this is here is because the new delta
between revisions N-1 and N may not contain a new kernel. If we don't run
SyncBootloaderFiles, how do we ensure that partition b gets the kernel from
revision N instead of revision N-2?

Correct me if I'm wrong!

[Michael Vogt (mvo)]

There are two calls here:
1. SyncBootloaderFiles() which will copy /boot/a -> /boot/b (or vice-versa)
2. HandleAssets() which will copy any new kernel in the update to /boot/b (or /boot/a)

The SyncBootloaderFiles was used becase ubuntu-device-flash did not provision both /boot/{a,b} initially. This is a fixed since so this extra copy is not needed anymore because both "a" and "b" are valid initially and get updated as new kernels come via updates. So unless I miss something I don't see a reason for SyncBootloaderFiles() to exist anymore.

[Michael Vogt (mvo)]

After thinking about this again I was wrong in my previous comment, we need to solve the following scenario:

1. kernel-a=1, kernel-b=1
2. update with new kernel=2 -> kernel-a=1, kernel-b=2
3. reboot to b, running with kernel-b=2
4. new update without changed kernel, system-a updated
6. reboot to system-a with kernel-a=1 (but it should be system-a with kernel-a=2 as we know kernel=2 works)

So there needs to be a step (5) that installs kernel version 2 as kernel-a.

Still I think we should make it smarter to avoid the huge delay, i.e. cp -au and cleanup afterwards instead of
rm -rf and cp -a.

[John Lenton (chipaca)]

note that https://code.launchpad.net/~chipaca/snappy/fsync/+merge/257726
and adding a call to syncfs before SyncBootFiles returns, and similar
fixes in several places of HandleAssets, should making mounting with
sync unnecessary and thus get rid of the huge delay.

On 29 April 2015 at 09:32, Michael Vogt <email address hidden> wrote:
> ** Changed in: snappy-ubuntu
> Status: New => Triaged
>
> ** Changed in: snappy-ubuntu
> Importance: Undecided => High
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to snappy-ubuntu.
> https://bugs.launchpad.net/bugs/1449032
>
> Title:
> delay when upgrading
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy-ubuntu/+bug/1449032/+subscriptions

[Michael Vogt (mvo)]

@John - indeed, we may consider mouting it async again. I'm hesitant going that for stable though and the kernel snap work will make some of this obsolete.

I created the linked branch that avoids the unneeded copies. The update is still very slow when there is a kernel update, but at least its not doing the copies now if nothing changed.