1

resize2fs takes extra 90 seconds to resize 2TB boot disk during boot on Debian 10 than on Debian 9.

Note that time to create/provision VM instance (gcloud compute instances create ...) is the same (around 10 seconds) for both Debian 9 and Debian 10, but time to successful SSH is different (see while loop in my test command) - this is when VM is actually booted, not when gcloud instances create ... returns.

Debian 9 image test for 10Gb and 2TB disk sizes - startup time is almost the same (around 1 minute):
$ VM=deb9-10gb; time gcloud compute instances create $VM --image-family=debian-9 --image-project=debian-cloud --boot-disk-size=10GB --machine-type=n1-standard-4 --scopes cloud-platform; date; time (while ! gcloud compute ssh $VM --command="hostname" 2>/dev/null; do date; done); date

Sat 25 Apr 2020 10:49:51 PM PDT
. . .
deb9-10gb

real    1m8.119s
user    0m2.593s
sys 0m0.398s
Sat 25 Apr 2020 10:50:59 PM PDT

$ VM=deb9-2tb; time gcloud compute instances create $VM --image-family=debian-9 --image-project=debian-cloud --boot-disk-size=2TB --machine-type=n1-standard-4 --scopes cloud-platform; date; time (while ! gcloud compute ssh $VM --command="hostname" 2>/dev/null; do date; done); date

Sat 25 Apr 2020 10:51:27 PM PDT
. . .
deb9-2tb

real    0m42.178s
user    0m1.505s
sys 0m0.240s
Sat 25 Apr 2020 10:52:09 PM PDT
Debian 10 image test for 10Gb and 2TB disk sizes - startup time is 90 seconds longer for VM w/ 2TB disk:
$ VM=deb10-10gb; time gcloud compute instances create $VM --image-family=debian-10 --image-project=debian-cloud --boot-disk-size=10GB --machine-type=n1-standard-4 --scopes cloud-platform; date; time (while ! gcloud compute ssh $VM --command="hostname" 2>/dev/null; do date; done); date

Sat 25 Apr 2020 11:01:35 PM PDT
. . .
deb10-10gb

real    1m11.145s
user    0m2.586s
sys 0m0.412s
Sat 25 Apr 2020 11:02:47 PM PDT

$ VM=deb10-2tb; time gcloud compute instances create $VM --image-family=debian-10 --image-project=debian-cloud --boot-disk-size=2TB --machine-type=n1-standard-4 --scopes cloud-platform; date; time (while ! gcloud compute ssh $VM --command="hostname" 2>/dev/null; do date; done); date

Sat 25 Apr 2020 11:03:27 PM PDT
. . .
deb10-2tb

real    2m49.483s
user    0m6.576s
sys 0m1.068s
Sat 25 Apr 2020 11:06:17 PM PDT

Interestingly, just after VM boot tune2fs shows that Debian 10 VM wrote 43 GB to boot disk, but Debian 9 only 2 GB:

deb9-2tb:~$ sudo tune2fs -l /dev/sda1 | grep "Lifetime writes:"
Lifetime writes:          2183 MB

deb10-2tb:~$ sudo tune2fs -l /dev/sda1 | grep "Lifetime writes:"
Lifetime writes:          43 GB

I also tested this with newer 1.45.5-2 e2fsprogs version on Debian 10 (updated from buster-backports repo) and Ubuntu 20.04 LTS. But only Debian 10 VM still have this regression, Ubuntu 20.04 LTS doesn't have it, so it seems that this is a Debian 10-specific issue.

Are there any configuration option that allows to restore Debian 9 behavior in Debian 10 for resize2fs during VM boot time?

  • I have checked and from my side the timings do not have that difference. Could you tell on which zone were you trying? – Israel Z Apr 27 '20 at 14:36
  • Yeah, `gcloud compute instances create ...` time will be the same, but time to successful SSH is different (see `while` loop in my test command) - when `gcloud create` returns VMs are still not initialized. Zone was `us-central1-c`. – Igor Dvorzhak Apr 27 '20 at 14:48
  • Have found that there is more discussion about this on the debian bug [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958982 – Israel Z May 08 '20 at 07:38

1 Answers1

0

Thanks to the diagnosis in the e2fsprogs bug report GCE team was able to fix this issue in GCE Debian 10 image and now Debian 10 VM creation with large boot disks as fast as was with Debian 9.

This fix included starting from the debian-10-buster-v20200714 GCE Debian 10 image.