it-swarm.com.de

Gibt es einen anderen Grund für "kein Platz mehr auf dem Gerät"?

Ich verwende Dirvish auf einem Ubuntu-Serversystem zum Sichern einer Festplatte auf einem externen USB 3.0-Laufwerk. Bis vor ein paar Tagen hat alles gut funktioniert, aber jetzt schlägt jede Sicherung mit "kein Speicherplatz mehr auf Gerät (28)" und "Dateisystem voll" fehl. Leider ist es nicht so einfach: Auf dem Gerät sind> 500 GB frei.

Einzelheiten:

rsync_error:

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

das Protokoll sieht so ziemlich wie gewohnt aus, bis es trifft:

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

Wie oben erwähnt, ist auf dem Gerät jedoch viel Platz:

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

und es sind auch noch viele Inodes übrig:

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

Das Gerät ist wie folgt montiert:

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

Der Prozess wird als root ausgeführt.

Ich wollte gerade sagen, dass ich nichts geändert habe, aber das stimmt nicht ganz: Ich habe acl für das Laufwerk eingeschaltet, das ich sichern möchte:

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

Könnte das das Problem sein? Wenn ja, wie? root hat weiterhin vollen Zugriff auf die Dateien.

BEARBEITEN:

Ich habe gerade die temporären Verzeichnisse überprüft:

  • / tmp enthält nur einen leeren .webmin-Ordner
  • / var/tmp ist leer

das Dateisystem, in dem sich diese Verzeichnisse befinden, verfügt über ausreichend freien Speicherplatz und Inodes:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2:

Die Verzeichnisse sind ziemlich groß, aber nicht> 2 GB. Die, bei der die Sicherung fehlschlägt, ist nicht einmal eine der größten, sondern enthält 7530 Dateien.

EDIT3:

Eine Information, die ich beim Posten dieser Frage nicht für relevant hielt:

Am Tag bevor die Sicherungen fehlschlugen, hatte ich acls auf den gesicherten Dateisystemen aktiviert. Ich gehe jetzt davon aus, dass dies Dirvish (oder rsync) dazu veranlasst hat zu glauben, dass sich alle Dateien geändert haben, sodass die Liste der Dateien, die kopiert und nicht fest verknüpft werden sollten, sehr groß war. Dies könnte möglicherweise bedeuten, dass einige Puffer zu klein waren.

Heute hat eine vollständige Sicherung auf einer leeren Festplatte einwandfrei funktioniert. Ich werde als nächstes eine inkrementelle Sicherung versuchen. Dies zeigt, ob die Aktivierung von acls die Ursache für das Problem war.

12
dummzeuch

Mein Verdacht (siehe EDIT3) war anscheinend richtig: Durch Hinzufügen von ACL-Unterstützung zum Dateisystem glaubte rsync/dirvish, dass sich alle Dateien geändert hatten. Anstatt eine inkrementelle Sicherung zu erstellen und nur feste Links zu den bereits vorhandenen Dateien zu erstellen, wurde versucht, eine vollständige Sicherung zu erstellen, was natürlich fehlschlug, weil die Festplatte nicht genügend Speicherplatz dafür hatte.

Die Fehlermeldung war also tatsächlich korrekt.

Nachdem Sie erneut mit einer leeren Sicherungsdiskette begonnen hatten, funktionierten die inkrementellen Sicherungen wie zuvor.

4
dummzeuch

Als ich mir die 2% der verbleibenden Inodes ansah, dachte ich über die Root-Reserven nach, die das EXT-Dateisystem auferlegt. Vielleicht möchten Sie diese überprüfen:

  1. " Reservierter Speicherplatz für root in einem Dateisystem - warum? "
  2. " Angemessene Größe für" Dateisystem reservierte Blöcke "für Nicht-Betriebssystem-Festplatten? "

Ich würde versuchen, einige der älteren Backups mit .tar.gz zu versehen, in der Hoffnung, dass dadurch die Anzahl der verwendeten Inodes verringert wird.

4
Vlad GURDIGA

Ich sehe, dass Dummzeuch eine Lösung für sein Problem findet, aber es gibt tatsächlich einen weiteren Fall, in dem die Festplatte genügend Inodes/freien Speicherplatz haben kann und beim Versuch, bestimmte Verzeichnisse zu übertragen, immer noch "kein Speicherplatz mehr auf dem Gerät" angezeigt wird.

Dies wird durch Hash-Kollisionen auf Blockgeräten verursacht, die mit dem ext4-Dateisystem formatiert sind, wobei auch die Verzeichnisindizierung aktiviert ist, insbesondere wenn in einem einzelnen Verzeichnis mehr als 100.000 Dateien gehostet werden und der Name der Dateien aus demselben Algorithmus generiert wird (Cache-Dateien, md5sum-Dateinamen usw. .)

Die Lösung besteht darin, es mit einem anderen Verzeichnisindizierungsalgorithmus zu versuchen:

tune2fs -E "hash_alg=tea" /dev/blockdev_name

oder um die Verzeichnisindizierung für dieses Blockgerät vollständig zu deaktivieren (kann die Leistung beeinträchtigen)

tune2fs -O ^dir_index /dev/blockdev_name

Eine andere Lösung besteht darin, zu sehen, was das Verzeichnis mit solchen Dateien füllt, und die Software zu reparieren.

Eine mögliche Lösung besteht darin, den Inhalt eines Ordners mit einem großen Dateivolumen in mehrere separate Unterordner aufzuteilen.

Die vollständige Beschreibung des Problems wird von Axel Wagner hier vorgestellt

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

Prost.

Es gibt eine Größenbeschränkung von 2 GB für das Verzeichnis selbst - d. H. Wenn Sie so viele Dateien haben, dass die Verzeichnisgröße> 2 GB ist (NICHT die Größe der Dateien im Verzeichnis), liegt ein Problem vor. Bei nur 2,8 Millionen verwendeten Inodes sollte dies jedoch kein Problem sein. Normalerweise passiert um 15M Inodes.

Das ist vielleicht keine große Hilfe - aber versuchen Sie es mit ext4 auf Ihrem Backup-Gerät?

1
Rafiq Maniar

Erhöhen Sie Ihr Inotify-Beobachterlimit in sysctl:

 Fs.inotify.max_user_watches = 100000 

Und neu starten oder sysctl -w Version davon auch.

Das wird es normalerweise tun. In etwas sind zu viele Dateien im Kernel geöffnet, und der Fehler ist völlig irreführend. Dropbox ist ein klassisches Beispiel dafür.

1
Sirex

Ich würde Ihnen vorschlagen, nach ein paar anderen Dingen zu suchen:

  1. Überprüfen Sie, ob Ihr temporäres Verzeichnis nicht voll ist. Manchmal wird es für die Zwischenlagerung verwendet und es wird leicht voll.
  2. Überprüfen Sie, ob es einen Prozess gibt, der noch einen Deskriptor für eine gelöschte Datei enthält. Die Wahrscheinlichkeit ist geringer, da df die richtige Größe meldet, aber es wird trotzdem nicht schaden.
0
Aditya Patawari

Ich habe dieses Thema gerade gefunden, als ich nach einer Lösung für mein Problem gesucht habe.

In der Tat gibt es zumindest einen anderen Grund für ENOSPC. Und ich habe es auch mit rsync gemacht, während ich von einem ZFS-Dateisystem auf ein EXT4-Dateisystem kopiert habe:

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

In diesem Fall:

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr erklärt:

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

In meinem Fall bedeutet dies, dass ich das gesamte Dateisystem neu formatieren muss. :-(