ZFS filesystem voll, dateien können nicht gelöscht werden

F

FVe9Zb7NWSgbh

Grünschnabel
Hallo zusammen!

Ich habe heute aus Testgründen bei einem Testsystem
folgendes gemacht:

mkfile 100G /opt/sis (oder so ähnlich). :think:, fragt nicht warum.

Das FS wurde zu 100% gefüllt.
Ich habe dieses (sehr grosse) File gelöscht. Das File ist
nun weg, aber das Filesystem ist trotzdem noch zu 100% voll.

Das File war sicherlich von keinem Prozess in use, ich hab dies nebenbei noch mit lsof geprüft.

Kennt jemand diesen Fehler? Was kann ich in diesem Fall tun?

Ps: SR bei SUN im Gange
Ps2: Ist mein erstes Posting hier, hab dieses Forum heute gefunden , ziemlich kuhl^^
 
Zuletzt bearbeitet:
Oft behebt ein simpler Reboot das Problem. Und ggf. mal einen Check mittels 'zpool scrub meinpool' drüberlaufen lassen.
 
Wo steht denn das da noch 100% belegt sind ?

Die ZFS-Statistiken in zfs list werden jedenfalls asynchron aktualisiert. Ansonsten schließe ich mich bitmuncher an - ein scrub kann durchaus helfen.

Psyjo
 
Hallo zusammen

Ich habe die Maschine gestern bereits rebootet und zpool scrub meinpool
habe ich ebenfalls ausgeführt.

Leider ist das Problem nicht gelöst...

Wo das steht, dass das FS 100% voll ist? Ehm, zfs list on globalzone sagt z.B., dass noch 150MB frei sind (habe ein paar Sachen gelöscht).
Und auf dem Server df -h sagt ebenfalls, dass das Filesystem 100% voll ist.

Habt ihr vielleicht noch andere Ideen?

Danke
Mulekk
 
Zuletzt bearbeitet:
Was gibt denn "zfs list" unter "avail" aus?

Kann es sein, das du einen Snapshot angeleget hast, der nun den Speicher frisst?
schau mal mit "zfs list -t snapshot" nach, ob hier vll. was dabei ist.

Du kannst auch noch das Gnome-Tool "Festplattenbelegung analysieren" nutzen - der Zeigt dir Grafisch, wo denn der Speicher verloren geht.
Am besten rufeste ihn mit "pfexec baobab" auf, um auch sicher auf alles Zugriff zu erlangen.

Viel Erfolg
Henri
 
Salü Henri

Danke für die Antwort!

zfs list:
150M Available....

wenn ich die snapshots aufliste, gibts ein
"no datasets available", also offenbar ist dies nicht das problem.

irgendwie ging bei der löschung des ca. 14Giga grossen File's etwas schief,
aber ich habe keinerlei Erfahrung mit ZFS und weiss nicht, was hier Sache ist. Das File ist wie gesagt weg, aber im Superblock siehts dann anders aus.

Sync hat auch nicht allzuviel gebracht^^
 
Hast du evtl. ein neues Boot-Environment angelegt und die Datei ist im alten noch vorhanden? Was gibt dir ein 'pfexec beadm list' aus? Irgendwelche BEs, die du löschen kannst?
 
danke für die hilfe, aber (mein fehler^^) ich vergass zu erwähnen, s ist ein sparc.:

pfexec bootadm list-menu
bootadm: not a GRUB based Solaris instance. Operation not supported

ich habe gerade eine interessante zfs doku gefunden (und darin etwas betreffend pending changes). vielleicht finde ich dort etwas interessantes. ich werde, falls/wenn ich eine lösung finde, dies jedenfalls hier reinschreiben!

aber dank für die hilfe soweit und bis später :)
 
Zuletzt bearbeitet:
bootadm hat mit beadm garnichts zu tun. bootadm managed die durch Grub bootbaren Systeme, während beadm die ZFS-Boot-Environments verwaltet.
 
Achso, sorry, mein Fehler.

Ist beadm standard? weil /usr/sbin/beadm
ist bei mir nicht vorhanden.

ich schaue am abend kurz und werde mich dann wieder meldne.
 
Bei OpenSolaris ist beadm eigentlich Standard. Es befindet sich allerdings in /sbin/beadm und /usr/sbin/beadm ist im Normalfall nur ein Link dorthin.
 
bitmuncher schrieb:
Hast du evtl. ein neues Boot-Environment angelegt und die Datei ist im alten noch vorhanden? Was gibt dir ein 'pfexec beadm list' aus? Irgendwelche BEs, die du löschen kannst?
Zum Vergrößern anklicken....

Nur wenn kein Snapshot vorhanden ist, auf welches das BE verweisen kann, wird auch kein BE vorhanden sein.
 
Ich bins nochmals^^ also zum Problem noch ein nachtrag:

Bei den ZFS Dokumentationen bin ich leider nicht weitergekommen, auch betreffend ZFS pending changes
habe ich nichts gefunden, dass mir bei meinem Problem helfen würde.
Jedenfalls hab ich mir heute kurz ein Testsystem aufgesetzt und habe ein paar Tests gemacht, um
den Fehler zu reproduzieren und so vielleicht die Ursache zu finden.

Darunter die für mich interessantesten:
1) Ich habe grössere Files erstellt, 10GB, 12 GB, usw. Das FS war maximal zu 90% voll (grösstes File ca. 13.5 GB). Ich konnte alle Files löschen also ZFS scheint sicherlich keine Probleme mit grösseren Files zu haben. (obwohl ich in einer Bugsammlung einen Artikel gefunden habe, wo beschrieben ist, dass ZFS Probleme hat mit Files in der Grössenordnung von 1 TB => no workaround).

2) Ich habe eine Quota auf 10GB gesetzt und dann das FS wiederum mit einem grösseren File gefüllt (bzw. bis zur Quota exceed-Meldung so ähnlich). Das löschen der Dateien ging Problemlos

3) Ich habe das Filesystem gefüllt mit mehreren kleineren Files (3GB, das letzte ein bisschen grösser, sodass das FS 100% voll war). Das löschen der Files war kein Problem

4) Unverändert:
- Ich habe neinstalliert auf die 20GB Platte
- habe einen Nonroot-User erstellt ,
- habe diesem einen Ordner im /opt erstellt mit entpsrechenden Berechtigungen.
- su - meinsupernonrootuser
- ich habe mit diesem User folgendes ausgeführt
Code: 
 /usr/sbin/mkfile 100G /opt/sis/gugus

Das File war insgesamt ca. 16GB gross und das Filesystem voll.
- Ich habe dieses File gelöscht (und es war auch weg)
- ich habe sync eingetippt
- ich habe gebootet (sogar zweimal, reboot und init 6^^)
Leider war das FS immernoch 100% voll.


Ich werde morgen noch weitere Tests machen, ich hoffe, dass ich zu diesem Problem noch mehr herausfinden kann.

Gruss und schöne obig
Mulekk
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Neueste Themen

Zurück
Oben