PBS 2.4-1: Ein fehlerhaftes Backup macht alle Backups einer VM unbrauchbar.

[fabian]

Guter Hinweis, ich schalte auf der Replica auch mal GC ab und schaue wie lange wir mit dem Storage auskommen...

Das Problem ist, der Sync zieht über die Index Datei nur die Chunks nach die ihm offiziell fehlen, da steht dann z.B. "skipped: 20 snapshot(s) (2023-06-11T19:00:02Z .. 2023-08-01T19:00:00Z) - older than the newest local snapshot".
Sollte aber ein alter Chunk fehlen dann weiß der Sync davon nichts! Eigentlich auch nicht so zufriedenstellend für einen "Sync"

ein "resync" feature ist in arbeit und wird vorraussichtlich sowohl "missing snapshots" als auch "missing/corrupt chunks" unterstuetzen. derzeit laesst sich das nur durch einen sync/pull der jeweiligen gruppe in einen neuen namespace erledigen - bereits vorhandene chunks werden dabei "recycled", fehlende neu von der remote instanz runtergeladen..

 

[RolandK]

wenn utime hier keinen fehler zurueck gibt, dann ist das wohl ein bug im NFS server.. automatische updates abzudrehen ist eine sache, aber explizit angeforderte updates nicht durchzufuehren ohne einen fehler zu "schmeissen" ist problematisch.

sehe ich auch so

hier wär vielleicht ein strace des python scripts interessant bzw. entspr. ausschnitt wo der syscall erfolgt, um sicherzugehen daß da kein error zurückkommt auf os/nfs ebene. wenn das keinen error liefert, würd ich das auch bug nennen.

 

[RolandK]

das sollte wie folgt gehen/aussehen:

# strace -f python3 /tmp/atime.py 2>&1 |grep utimensat utimensat(AT_FDCWD, "myfile.txt", [{tv_sec=-3600, tv_nsec=0} /* 1970-01-01T00:00:00+0100 */, {tv_sec=1693481839, tv_nsec=507617950} /* 2023-08-31T13:37:19.507617950+0200 */], 0) = 0

 

[mow]

wenn utime hier keinen fehler zurueck gibt, dann ist das wohl ein bug im NFS server.. automatische updates abzudrehen ist eine sache, aber explizit angeforderte updates nicht durchzufuehren ohne einen fehler zu "schmeissen" ist problematisch.

Kann die fs-Funktion überhaupt wissen, ob das Update im- oder explizit ist, oder geht die Information in der Aufrufkette unter?
Und wenn das einen Fehler werfen sollte, welchen? Müßte nicht derselbe Fehler geworfen werden, wenn relatime das Update unterdrückt, so daß die GC diesen Fehler sowieso grundsätzlich ignorieren würde?

Ich bin der Meinung, daß das fs (welches ist hier eigentlich noatime gemountet? Das nfs oder das darunterliegende fs des Servers?) hier genau das tut, was man mit noatime angefordert hat. Daher ist das IMHO auch kein Bug.

 

[fabian]

Kann die fs-Funktion überhaupt wissen, ob das Update im- oder explizit ist, oder geht die Information in der Aufrufkette unter?

ja, natuerlich.

Und wenn das einen Fehler werfen sollte, welchen? Müßte nicht derselbe Fehler geworfen werden, wenn relatime das Update unterdrückt, so daß die GC diesen Fehler sowieso grundsätzlich ignorieren würde?

nein, relatime "verschleppt" nur die automatischen updates der timestamps die als seiteneffekt von anderen operationen gemacht werden. das explizite setzen ist von relatime nicht betroffen. als fehler wuerde z.b. EINVAL oder EROFS oder u.U. EPERM in frage kommen. aber eigentlich muss ein POSIX-kompatibles FS utimensat unterstuetzen, und die fehler die auftreten koennen sind spezifiziert..

Ich bin der Meinung, daß das fs (welches ist hier eigentlich noatime gemountet? Das nfs oder das darunterliegende fs des Servers?) hier genau das tut, was man mit noatime angefordert hat. Daher ist das IMHO auch kein Bug.

noatime bezieht sich auf "kein automatisches updaten der timestamps bei access", nicht "timestamps sind nicht schreibbar".

 

[mow]

nein, relatime "verschleppt" nur die automatischen updates der timestamps die als seiteneffekt von anderen operationen gemacht werden. das explizite setzen ist von relatime nicht betroffen. als fehler wuerde z.b. EINVAL oder EROFS oder u.U. EPERM in frage kommen. aber eigentlich muss ein POSIX-kompatibles FS utimensat unterstuetzen, und die fehler die auftreten koennen sind spezifiziert..

noatime bezieht sich auf "kein automatisches updaten der timestamps bei access", nicht "timestamps sind nicht schreibbar".

Moooment. Wenn utime[ns]at (das von `touch` benutzt wird) über setattr direkt auf den inode zugreift und sich nicht um noatime bzw. relatime kümmert, wieso gibt es dann die Krücke mit den 24h Extra-Wartezeit wegen relatime? Ich dachte, im Zuge der GC wird alles, was noch referenziert wird, getoucht?

 

[fabian]

Moooment. Wenn utime[ns]at (das von `touch` benutzt wird) über setattr direkt auf den inode zugreift und sich nicht um noatime bzw. relatime kümmert, wieso gibt es dann die Krücke mit den 24h Extra-Wartezeit wegen relatime? Ich dachte, im Zuge der GC wird alles, was noch referenziert wird, getoucht?

haben wir intern auch schon diskutiert, aber uns noch nicht durchgerungen, uns darauf zu verlassen dass das wirklich alle richtig machen/implementiert haben (und wenns um GC geht, gilt definitiv die devise "better safe than sorry"). wir verwenden uebrigens nicht "touch", sondern tatsaechlich direkt utimensat (so wie touch auch )