Unmount eines LVM Snapshots erzeugt hohe I/O-Last

[syssi]

Hi,

seit Debian Squeeze ist das Unmounten von LVM-Snapshots nach einem Backup eine Qual. Unter Debian Lenny dauert es lediglich einen Augenblick, anschliessend kann das Volumen per lvremove entfernt werden und das Backup ist beendet. Unter Squeeze (Kernel 2.6.32-5-amd64, LVM2 2.02.66-5) dauert es Minuten bis Stunden bis der umount erfolgreich war. Schaut man sich waehrenddessen per iotop die I/O-Last an, so sieht man:

Code: Alles auswählen

15530 be/4 root        0.00 B/s    0.00 B/s  0.00 %  99.99 % [kdmflush]
15554 be/4 root        0.00 B/s    0.00 B/s  0.00 %  99.99 % [kjournald]
15535 be/4 root        0.00 B/s    0.00 B/s  0.00 %  99.99 % [kcopyd]

Mich wundert, wer dort Daten schreibt. Vorallem ist ein Schreiben für meinen Fall völlig sinnfrei, da ich das Snapshot im Anschluss sowieso verwerfe. Ich versuche nun das Verhalten auf einem zweiten System zu reproduzieren. Ich habe die Hoffnung das Problem umgehen zu koennen, indem ich ein read-only Snapshot erstelle. Zu Debian Lenny-Zeiten waren die Snapshots jedoch auch schon read-write und haben keine solche I/O-Last erzeugt. Jemand eine Idee?

Gruss syssi

[Cae]

Der Snapshot ist ja die Anweisung, nachfolgende Schreibvorgänge irgendwie vom jetzigen Stand getrennt zu halten, so dass dieser konsistent bleibt. Die Schreibvorgänge passieren ja trotzdem und müssen mit dem Löschen des Snapshots zumindest wieder in die "Haupt-Datenbank" eingepflegt werden. Das kann schon dauern, wenn da tatsächlich Daten kopiert werden, imho würde es aber Sinn machen, nur die Informationen, wo die Daten gerade liegen, zu synchronisieren. Dieser Vorgang sollte recht fix gehen, das ist auch meine Beobachtung. (Wie) verändert ein vorhergehendes sync das Verhalten?

Gruß Cae

[syssi]

Hier ein paar ein paar Details:

Ich habe ein Testsystem mit einer Minimalinstallation aufgesetzt, auf welchem sonst nichts weiter laeuft. So sieht mein nachgestellter Backupvorgang aus:

Code: Alles auswählen

$ lvcreate --size 1G -s --name /dev/vg0/root_snap /dev/vg0/root
  Logical volume "root_snap" created
$ mount /dev/vg0/root_snap /mnt/backup
$ rsync -avz /mnt/backup remote:~
[...]
sent 295871578 bytes  received 652496 bytes  2980141.45 bytes/sec
total size is 727073023  speedup is 2.45
$ time umount /mnt/backup
real 0m37.218s
user 0m0.000s
sys 0m0.052s
$ lvremove -f /dev/vg0/root_snap
  Logical volume "root_snap" successfully removed

Noch einmal mit an vorherigem sync:

Code: Alles auswählen

$ lvcreate --size 1G -s --name /dev/vg0/root_snap /dev/vg0/root
  Logical volume "root_snap" created
$ mount /dev/vg0/root_snap /mnt/backup
$ rsync -avz /mnt/backup remote:~
[...]
sent 295875469 bytes  received 652591 bytes  2980181.51 bytes/sec
total size is 727083513  speedup is 2.45
$ time sync
real 0m0.025s
user 0m0.008s
sys 0m0.004s
$ time umount /mnt/backup
real 0m0.062s
user 0m0.000s
sys 0m0.052s

Jetzt war ich verblueffelt.. schliesslich sollte man glauben, dass nun sync lange braucht. Also nochmal ohne sync wiederholen:

Code: Alles auswählen

....
sent 295930810 bytes  received 652686 bytes  2980738.65 bytes/sec
total size is 727344090  speedup is 2.45
$ time umount /mnt/backup 

real 0m39.591s
user 0m0.000s
sys 0m0.056s

Wenn das Flushen per "sync" das Problem wirklich loest, dann spendiere ich meinem Backupskript eine weitere Zeile. Sinn macht das Alles aber nicht.

[syssi]

Code: Alles auswählen

for L in $(seq 1 10); 
do 
  lvcreate --size 1G -s --name /dev/vg0/root_snap /dev/vg0/root
  mount /dev/vg0/root_snap /mnt/backup
  ssh root@sheldon rm -rf ~/backup
  rsync -az /mnt/backup root@sheldon:~/backup
  time sync
  time umount /mnt/backup
  lvremove -f /dev/vg0/root_snap
done

geht fix und benoetigt weniger als 2 Sekunden.

Code: Alles auswählen

for L in $(seq 1 10); 
do 
  lvcreate --size 1G -s --name /dev/vg0/root_snap /dev/vg0/root
  mount /dev/vg0/root_snap /mnt/backup
  ssh root@sheldon rm -rf ~/backup
  rsync -az /mnt/backup root@sheldon:~/backup
  time umount /mnt/backup
  lvremove -f /dev/vg0/root_snap
done

benoetigt nach dem Kopieren von 730mb ca. 40 Sekunden. Werden die gelesenen Datenmengen groesser, so waechst die Wartezeit fuer das umount.

[habakug]

Hallo!

Es gab mal Probleme mit ext4 und Kernel 2.6.32 [1]. Geht es denn um dieses Dateisystem? Schon einen "aktuelleren" Kernel probiert?

Gruß, habakug

[1] https://bugzilla.kernel.org/show_bug.cgi?id=15906

[syssi]

Ich möchte mich nur ungern von Kernel 2.6.32 trennen. Es handelt sich eigentlich um ein ext3-Dateisystem. Interessant ist aber folgender Beitrag:

As an interesting oddity, creating an ext3 filesystem, but then attempting to
mount it as ext4 shows the same pathological behavior. Mounting as ext3, it's
fine again.

Das Dateisystem gebe ich nicht mit an, deshalb kann es sein, dass die Magie zu ext4 greift, um ext3 zu mounten. Schaut man nach dem mount in die /etc/mtab, so findet man "ext3". Zur Sicherheit habe ich dem mount mal ein "-t ext3" mitgegeben. Das Ergebnis sieht so aus:.

Code: Alles auswählen

for L in $(seq 1 10); do lvcreate --size 1G -s --name /dev/vg0/root_snap /dev/vg0/root; mount -t ext3 /dev/vg0/root_snap /mnt/backup; ssh root@sheldon rm -rf ~/backup; rsync -az /mnt/backup root@sheldon:~/backup ; time umount /mnt/backup ; lvremove -f /dev/vg0/root_snap; done
  Logical volume "root_snap" created
real    0m40.731s
user    0m0.000s
sys     0m0.052s

Es bleibt bei 40 Sekunden. Aber der Beitrag/Link ist trotzdem verblüffend nah ein meinem Problem. Vielen Dank!

Gruss syssi