Redimensionnement lent du disque pendant l'amorçage sur les VMs avec des images Debian 10 Buster sur GCP

resize2fs Il faut 90 secondes de plus pour redimensionner le disque d'amorçage de 2 To pendant l'amorçage sur Debian 10 que sur Debian 9.

Notez que le temps de création/provisionnement d'une instance de VM ( gcloud compute instances create ... ) est le même (environ 10 secondes) pour Debian 9 et Debian 10, mais le temps nécessaire à la réussite de SSH est différent (voir while dans ma commande de test) - c'est le moment où la VM est réellement démarrée, et non pas le moment où la VM est démarrée, et non pas le moment où la VM est démarrée. gcloud instances create ... les retours.

Test de l'image Debian 9 pour des disques de 10 Go et 2 To - le temps de démarrage est presque le même (environ 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

Test de l'image Debian 10 pour des disques de 10 Go et de 2 To - le temps de démarrage est plus long de 90 secondes pour la VM avec un disque de 2 To :

$ 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

Il est intéressant de noter que juste après le démarrage de la VM tune2fs montre que la VM Debian 10 a écrit 43 Go sur le disque d'amorçage, alors que la VM Debian 9 n'a écrit que 2 Go :

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

J'ai également testé cette méthode avec des versions plus récentes de 1.45.5-2 e2fsprogs sur Debian 10 (mise à jour de buster-backports ) et Ubuntu 20.04 LTS. Mais seule la VM Debian 10 a encore cette régression, Ubuntu 20.04 LTS ne l'a pas, il semble donc qu'il s'agisse d'un problème spécifique à Debian 10.

Existe-t-il une option de configuration qui permette de restaurer le comportement de Debian 9 dans Debian 10 pour resize2fs pendant le démarrage de la VM ?