Verwendet man MinIO (GitHub) als S3-kompatiblen Speicherdienst kann es unter Umständen vorkommen das man über den Fehler “507 insufficient storage” stolpert.

Live beobachten kann man dies beispielsweise unter

Monitoring - Trace

nach der Auswahl von “All” oder einem der einzelnen Punkte:

Wird restic als Backup-Lösung, die auf MinIO als Ziel setzt, verwendet sieht die Meldung in etwa so aus:

Save(<lock/1135d2b4b5>) returned error, retrying after 737.237499ms: client.PutObject: Storage backend has reached its minimum free drive threshold. Please delete a few objects to proceed.

Die Meldung (sowohl in MinIO und folglich in restic) kann allerdings irreführend sein. Im ersten Moment könnte man meinen, man hat nicht mehr genug freien Speicherplatz, das muss allerdings nicht unbedingt so sein. Der Hintergrund hierzu ist relativ einfach (wenn man es weiß):

  • MinIO fragt bei Storage-Aktivitäten ab, wie viel Speicherplatz noch frei ist.
  • Sind weniger als 2% frei oder andersherum mehr als 98% belegt werden keine Schreibvorgänge mehr zugelassen.

Diesen Schwellenwert habe ich in der Dokumentation nicht gefunden (oder übersehen. Wer was weiß, bitte ein Kommentar hinterlassen), Hinweise darauf fanden sich bei GitHub (siehe Quellen). Jedenfalls sind prozentuelle Schwellenwerte durchaus problematisch, denn 1-2 % können bei einem sehr großen Storage sehr viel Platz (z.B. mehrere hundert Gigabyte) bedeuten, ergo bleibt mitunter viel Platz ungenutzt.

Ändern kann man den Schwellenwert nicht. Soweit eine Recherche ergeben hat haben die Entwickler auch nicht vor hieran etwas zu ändern oder konfigurierbar zu machen. Irgendwie nachvollziehbar, aber auch Schade. Sofern man den Speicherplatz nicht erweitern kann (z.B. Singel-Disk, kein Storage-Pool oder Cluster, keine virtuelle Festplatte, etc.) bleibt nur Daten zu löschen bzw. nach extern zu verschieben.

Eine weitere potentielle Ursache zumindest unter Linux für die Fehlermeldung kann darin bestehen, das die maximale Anzahl an Inodes erreicht ist, diese ist unabhängig vom Speicherplatz. Unter Windows gibt es diese Begrenzung so nicht, obwohl es mit den FileIDs eine ähnliche (nennen wir es mal) Nummerierung/Strukturierung gibt.

Unter Linux lassen sich die belegten Inodes mit

ls -i

prüfen.

Quellen

GitHub – minio/minio – Issues – [resolved] 507 Insufficient Storage / harddisk is not full #10268

stackoverflow – Does Windows have Inode Numbers like Linux?

GitHub – minio/minio – Issues – Storage backend has reached its minimum free drive threshold. Please delete a few objects to proceed. #16185

GitHub – minio/minio – Issues -Storage backend has reached its minimum free disk threshold #6795