Kein Speicherplatz auf dem Gerät beim Entfernen einer Datei unter OpenSolaris

Beim Versuch, eine NFS-Freigabe (von einem OpenIndiana- Server exportiert ) auf einer Client-Box bereitzustellen, stürzte der OI-Server ab. Ich bekam den schwarzen Bildschirm des Todes, der wie ein Holzauszug aussah, dann wurde das System angepasst. Es wurde nie wieder angezeigt und ich erhalte die folgende Fehlermeldung, nachdem ich den Startvorgang angehalten habe:

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

Ich habe nichts anderes auf dem Boot-Laufwerk als das Betriebssystem, also ... bin ich mir nicht sicher, was das Laufwerk füllen könnte? Vielleicht eine Protokolldatei? Ich kann anscheinend nichts löschen. Es gibt mir einen Fehler ohne Leerzeichen, wenn ich versuche, etwas zu löschen:

$ rm filename
cannot remove 'filename' : No space left on device 

Ich kann mich im "Wartungsmodus" anmelden, aber nicht in der Standardbenutzeraufforderung.

Die Ausgabe von dfist:

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

Die Ausgabe von mountist:

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

Die Ausgabe von 'zfs list -t all' lautet:

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Ok, das ist komisch ... nicht genug Platz, um eine Datei zu entfernen!

Dies stellt sich als relativ häufiges Problem bei ZFS heraus, obwohl es möglicherweise auf jedem Dateisystem mit Snapshots auftreten kann .

Die Erklärung ist, dass die Datei, die Sie löschen möchten, in einem Snapshot noch vorhanden ist. Wenn Sie es löschen, bleibt der Inhalt erhalten (nur im Schnappschuss). und das System muss zusätzlich die Information schreiben, dass der Snapshot die Datei enthält, der aktuelle Status jedoch nicht. Es ist kein Platz mehr für diese zusätzlichen Informationen.

Eine kurzfristige Lösung besteht darin, eine Datei zu finden, die nach dem letzten Snapshot erstellt wurde, und sie zu löschen. Eine andere Möglichkeit besteht darin, eine Datei zu finden, an die nach dem letzten Snapshot angehängt wurde, und sie auf die Größe zu kürzen, die sie zum Zeitpunkt des letzten Snapshots hatte. Wenn Ihre Festplatte voll wurde, weil Ihre Protokolle durch Spam beschädigt wurden, versuchen Sie, die größten Protokolldateien zu kürzen.

Eine allgemeinere Lösung besteht darin, einige Schnappschüsse zu entfernen. Sie können Schnappschüsse mit auflisten zfs list -t snapshot. Es scheint keine einfache Möglichkeit zu geben, vorherzusagen, wie viel Speicherplatz zurückgewonnen wird, wenn Sie einen bestimmten Snapshot zerstören, da die darin gespeicherten Daten möglicherweise von anderen Snapshots benötigt werden und daher weiterleben, wenn Sie diesen Snapshot zerstören. Sichern Sie Ihre Daten bei Bedarf auf einer anderen Festplatte, identifizieren Sie einen oder mehrere Snapshots, die Sie nicht mehr benötigen, und führen Sie sie aus zfs destroy name/of/snap@shot.

In diesem OpenSolaris-Forenthread wird dieses Problem ausführlich behandelt .

Dies ist ein bekanntes Problem bei Copy-on-Write-Dateisystemen: Um eine Datei zu löschen, muss das Dateisystem zunächst einen Block zuweisen und den neuen Status korrigieren, bevor der in der gerade gelöschten Datei enthaltene Speicherplatz freigegeben werden kann.

(Es ist kein Problem von Dateisystemen mit Snapshots, da es andere Möglichkeiten gibt, diese zu implementieren, als nur beim Schreiben zu kopieren.)

Wege aus dem Squeeze:

• Geben Sie einen Schnappschuss frei (falls es einen gibt ...)
• Erweitern Sie den Pool (falls noch Ersatz übrig ist, den Sie ihm zuweisen können)
• Zerstören Sie ein anderes Dateisystem im Pool und erweitern Sie dann das enge Dateisystem
• Schneiden Sie die Datei ab und entfernen Sie sie dann (obwohl ich, sobald ich zu eng war, um das auch zu können, siehe Thread bei ZFS Discuss ).
• Verknüpfung der Datei aufheben. (das gleiche wie oben)

Ich bin vor ein paar Jahren in dieselbe Falle geraten und hatte keine Schnappschüsse, die ich hätte veröffentlichen können, um mich zu befreien. Siehe den Thread bei ZFS. Diskutieren Sie, wo dieses Problem ausführlich besprochen wurde.

4.Z3G (Spalte rpool / root USED) ist zweifelhaft.

In jedem Fall ist rpool / export / home / admin zu groß (3,85 GB) wahrscheinlich die Hauptursache. Schauen Sie sich den Inhalt an und entfernen Sie dort unnötige Dateien. Da das Admin-Dateisystem keine Snapshots enthält, sollte sofort Speicherplatz im Pool frei werden.

Ich hatte das und verbrachte eine Weile damit, herauszufinden, was gebraucht wurde. Meine Lösung bestand darin, den Speicherplatz der Dateien auf Null zu setzen, bevor ich versuchte, sie zu löschen.

Wir haben einige Fehlverhaltensprozesse, die gelegentlich verrückt werden und die Festplatte mit Kerndateien füllen (die mit einer Zahl enden). Deshalb habe ich ein Skript erstellt, das so etwas enthält, um eine Kopie zu behalten.

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

Als ich mein Skript ausführte, gab es einen Fehler:

mv: cannot rename core.200000 to core: No space left on device

und funktionierte beim Löschen der Dateien.

Um dies zu testen, füllte ich die Diskette mit:

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done