PBS / Hetzner StorageBox / CIFS -> "status access time safety check failed"

[tscherle]

Hallo zusammen,

Ich versuche aktuelle eine StorageBox (von Hetzner), die per CIFS an einen PBS-Server gemountet ist, als Datastorage einzurichten, was in einem Fehler endet.
Beispiel-Fehler:

...
Chunkstore create: 97%
Chunkstore create: 98%
Chunkstore create: 99%
Chunk metadata was not correctly updated during access time safety check:
Timestamps before update: accessed Some(SystemTime { tv_sec: 1757495267, tv_nsec: 845989100 }), modified Some(SystemTime { tv_sec: 1757495267, tv_nsec: 845989100 }), created Some(SystemTime { tv_sec: 1757495267, tv_nsec: 845989100 })
Timestamps after update: accessed Some(SystemTime { tv_sec: 1757495254, tv_nsec: 202709600 }), modified Some(SystemTime { tv_sec: 1757495267, tv_nsec: 845989100 }), created Some(SystemTime { tv_sec: 1757495267, tv_nsec: 845989100 })
TASK ERROR: access time safety check failed: access time safety check using newly inserted chunk failed, aborting GC!
Error: task failed (status access time safety check failed: access time safety check using newly inserted chunk failed, aborting GC!)

In diesem Forum habe ich den Fehler schon ein paar mal gesehn, aber leider konnte ich keine Lösung aus den Threads ableiten.
Leider finde ich auch kaum Informationen darüber, was genau dieser Check macht und warum die in der Fehlermeldung angegebenen Werte/Zeiten nicht wie erwartet sind.

Hat jemand dazu vielleicht mehr Informationen?

 

[Hannes Laimer]

Hey,

es wird geprüft ob das Dateisystem atime updates respektiert, also diese korrekt speichert. Hier scheint CIFS das nicht zu tun, garbage collection stellt mit der accestime feststellt ob ein chunk weg kann. Grob gesagt werden gebrauchte chunks eben damit als "gebraucht" markiert, dieser Fehler weist darauf hin, dass das Markieren mit dem Dataeisytem auf welchem der Datastore liegt nicht funktioniert.

 

[tscherle]

Danke Dir für die Beschreibung. Allerdings bin ich mir jetzt immer noch nicht sicher, was denn genau nicht funktioniert.
Wenn ich die Timestamps aus der Fehlermeldung nehme, sieht das so aus:

Timestamps before update:
accessed { tv_sec: 1757495267, tv_nsec: 845989100 }, modified { tv_sec: 1757495267, tv_nsec: 845989100 }, created { tv_sec: 1757495267, tv_nsec: 845989100 }
Timestamps after update:
accessed { tv_sec: 1757495254, tv_nsec: 202709600 }, modified { tv_sec: 1757495267, tv_nsec: 845989100 }, created { tv_sec: 1757495267, tv_nsec: 845989100 }

Was ist denn jetzt "falsch"?
Und was genau erwartet PBS?

 

[Falk R.]

Danke Dir für die Beschreibung. Allerdings bin ich mir jetzt immer noch nicht sicher, was denn genau nicht funktioniert.
Wenn ich die Timestamps aus der Fehlermeldung nehme, sieht das so aus:

Timestamps before update:
accessed { tv_sec: 1757495267, tv_nsec: 845989100 }, modified { tv_sec: 1757495267, tv_nsec: 845989100 }, created { tv_sec: 1757495267, tv_nsec: 845989100 }
Timestamps after update:
accessed { tv_sec: 1757495254, tv_nsec: 202709600 }, modified { tv_sec: 1757495267, tv_nsec: 845989100 }, created { tv_sec: 1757495267, tv_nsec: 845989100 }

Was ist denn jetzt "falsch"?
Und was genau erwartet PBS?

Der PBS erwartet, das dein Speicher (hier SMB) saubere atime Werte liefert. Entweder hast du beim Mounten eventuell noatime mitgegeben?
Das machen manche Backuphersteller um Performance raus zu holen.

 

[tscherle]

Der PBS erwartet, das dein Speicher (hier SMB) saubere atime Werte liefert. Entweder hast du beim Mounten eventuell noatime mitgegeben?
Das machen manche Backuphersteller um Performance raus zu holen.

Nein, beim mounten nutze ich keine speziellen Parameter.
Zur Vollständigkeit:

//u00000000-sub1.your-storagebox.de/u00000000-sub1 /mnt/storagebox cifs iocharset=utf8,rw,credentials=/etc/smb-creds,uid=34,gid=34,file_mode=0660,dir_mode=0770 0 0

"Der PBS erwartet, das dein Speicher (hier SMB) saubere atime Werte liefert."
Aber was wären denn die sauberen atime Werte? Gerade in Bezug auf die Fehlermeldung bzw die dort gemeldeten Timestamps? Genau das sagt die Fehlermeldung leider nicht

 

[Falk R.]

atime ist ein Wert, den jedes Dateisystem und auch Netzwerkdateisystem wie SMB oder NFS kann.
Eventuell muss es auf der SB aktiviert werden oder in der SMB Verbindung. Der PBS fragt nur ab ob das Dateisystem einen atime Wert liefert. Wenn da keiner kommt, gibt es diese Fehlermeldung.

P.S. ich würde niemals ein SMB Speicher an einem PBS nutzen und im Internet erst recht nicht. VZDump Backups lufen bestimmt ganz OK zu einer SB, aber der PBS braucht für seinen Datastore wegen der eingebauten Deduplizierung schnellen Speicher.
Klar kann das funktionieren, aber wird nie Spaß machen.

 

[tscherle]

Danke erstmal für deine Erklärung, aber das lässt leider immer noch Fragen offen.

Die Fehlermeldung sagt;
Chunk metadata was not correctly updated during access time safety check

und in den folgenden Detaiuls sieht man jeweils Timestamps:

Timestamps before update:
accessed { tv_sec: 1757495267, tv_nsec: 845989100 }, modified { tv_sec: 1757495267, tv_nsec: 845989100 }, created { tv_sec: 1757495267, tv_nsec: 845989100 }
Timestamps after update:
accessed { tv_sec: 1757495254, tv_nsec: 202709600 }, modified { tv_sec: 1757495267, tv_nsec: 845989100 }, created { tv_sec: 1757495267, tv_nsec: 845989100 }

Die Frage ist jetzt, was fehlt hier PBS? bei "before" und "after" sind Timestamps für "accessed" (atime) enthalten.
Dann scheint ein Wert unerwartet zu sein? aber welcher und warum? Leider sagt die Fehlermeldung das nicht speziefischer.

 

[Falk R.]

Ich habe da auch nicht viel Ahnung von, aber für mich sieht die Access Time nachher kleiner aus als vorher.

 

[Hannes Laimer]

Jap daran liegts, accessed ist vor dem update größer (also neuer), als nach dem update. Als Referenz, hier der relevant Code [1] für diesen Fehler.
Es wird also erwartet, dass sich die atime nach einem update der Datei geändert hat, idealerweise in Richtung Gegenwart

[1] https://git.proxmox.com/?p=proxmox-...017655232bf16e3e219f1fe3ebb10b509217ccda#l505

 

[tscherle]

Jap daran liegts, accessed ist vor dem update größer (also neuer), als nach dem update. Als Referenz, hier der relevant Code [1] für diesen Fehler.
Es wird also erwartet, dass sich die atime nach einem update der Datei geändert hat, idealerweise in Richtung Gegenwart

[1] https://git.proxmox.com/?p=proxmox-...017655232bf16e3e219f1fe3ebb10b509217ccda#l505

Super! Vielen Dank für deine Antwort und den Link zum Code. Das macht es definitiv klarer, was passier tund erwartet wird.

Also passiert etwa folgendes

insert_chunk()

before = metadata_before()

change_atime_of_chunk()

after = metadata_now()

if (before >= after) {
    ERROR
}

In meinem Fehlerfall ist also die atime VOR einer Aktualisierung der atime größer bzw. weiter in der Zukunft als der Timestamp NACH der Anpassung der atime.
Da die Timestamps jeweils vom Clients, also vom PBS gesetzt werden, kann ich mir nicht erklären wie das überhaupt möglich sein kann.
Oder anders gesagt: beim erstellen des Chunks wird ein jüngerer Timestamp gesetzt als der, der bei einer anhschließenden Anpassung (touch) gesetzt wird.
Hat jemand eine Idee?