Auf die Festplatte kann nicht geschrieben werden, die Festplatte ist jedoch nicht voll

Ich verwende Ubuntu 12.04 und kann nicht in eine Datei schreiben, auch nicht als root, oder andere Operationen ausführen, die das Schreiben erfordern. Ebenso wenig kann ein Prozess geschrieben werden, sodass alle fehlschlagen. dfsagt, ich habe viel Platz:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G   14G   15G  48% /
udev            984M  4.0K  984M   1% /dev
tmpfs           399M  668K  399M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            997M     0  997M   0% /run/shm

Alle Ergebnisse, die ich für "Ich kann nicht auf die Festplatte schreiben" finde, beziehen sich auf berechtigte vollständige Festplatten. Ich weiß nicht einmal, wo ich anfangen soll. Das Problem ist heute Morgen aus dem Nichts aufgetaucht.

Der letzte Protokolleintrag von PHP lautet:

fehlgeschlagen: Kein Platz mehr auf dem Gerät (28)

Vim sagt:

Datei kann nicht zum Schreiben geöffnet werden

Andere Anwendungen führen zu ähnlichen Fehlern.

Nach dem Löschen von ~ 1GB bleibt das Problem bestehen. Ich habe auch neu gestartet.

df -i sagt

Filesystem      Inodes   IUsed  IFree IUse% Mounted on
/dev/xvda1     1966080 1966080      0  100% /
udev            251890     378 251512    1% /dev
tmpfs           255153     296 254857    1% /run
none            255153       4 255149    1% /run/lock
none            255153       1 255152    1% /run/shm

hard-drive filesystems diskmanagement

— Glückwunsch
quelle

Bitte posten Sie die Ausgabe von "df -i".

— EEAA

@EEAA bearbeitet in. Du hast recht, df -i sagt 100%. Was bedeutet das? Warum sollte es anders sein?

— Felwithe

IIRC: Zu viele Dateien in einem einzigen Verzeichnis weisen ähnliche, wenn nicht identische Symptome auf. Was "zu viel" ist, variiert zwischen Dateisystemen.

— MSalters

Antworten:

Sie haben keine Inodes mehr. Es ist wahrscheinlich, dass Sie irgendwo ein Verzeichnis mit vielen sehr kleinen Dateien haben.

— EEAA
quelle

Ich wollte nur hinzufügen, dass ich nicht einmal wusste, dass rm es scheitern könnte . Dies war eine Ausbildung.

— Felwithe

@felwithe, ich kann mir vorstellen, dass find . -name sess\* -exec rm {} +das geklappt hätte.

— Carsten S

@felwithe Was andere vorgeschlagen haben. rm Wahrscheinlich hat es gut funktioniert, aber die Shell hat den *Globus in viel zu viele Daten erweitert und barfed, bevor es überhaupt soweit war, rm aufzurufen .

— ein Lebenslauf

@CarstenS: Oder find . -name sess\* -deletewas ich mir leichter merken kann und was im Allgemeinen effizienter ist.

— MSalters

@Kaslai das Limit gibt es nicht RAM, sondern das Systemlimit ARG_MAX. Der POSIX-Standard gibt leider nicht genau an, wie Befehlszeilenargumente gegen ARG_MAX gemessen werden. Einige Implementierungen sind unbegrenzt und definieren daher ARG_MAX nicht. Dies ist jedoch keine beliebte Option, da zu viele Programme nicht kompiliert werden können.

— James Youngman

Anscheinend hat das OP eine Antwort auf ihr spezielles Problem. Der Vollständigkeit halber können die Symptome des OP jedoch auch auftreten, wenn das Dateisystem schreibgeschützt erneut bereitgestellt wurde. Dies ist mir mit einer Linux-VM passiert, deren Speicher auf einem Cluster-Festplattensystem lag und bei der nur selten zeitweise Fehler auftraten. Gelegentlich führten die Fehler dazu, dass die Dateisysteme schreibgeschützt erneut bereitgestellt wurden. Das schließlich beobachtbare externe Symptom war, dass verschiedene Dienste nicht mehr reagierten, wenn der Arbeitsspeicher voll war (mit Schreibvorgängen für nicht entleerbare Datenträger).

Zu diesem Zeitpunkt bestand die einzige Lösung darin, das System neu zu starten (wobei alle ungeschriebenen Protokolle verloren gingen). Versuche, RW erneut einzuhängen, schlugen fehl. (Leider kann ich mich nicht an die Fehlermeldungen erinnern, die beim Versuch dieser Remounts zurückgegeben wurden.)

Also, nicht das Problem des OP, sondern jemand anderes, der auf dieser Seite ankommt, kann von diesen Informationen profitieren.

— Eric Towers
quelle

Nicht wirklich; Wenn das Dateisystem wieder als schreibgeschützt bereitgestellt wurde, wird eine Fehlermeldung angezeigt, die besagt, dass das Dateisystem schreibgeschützt ist und nicht über genügend Speicherplatz verfügt.

— Psusi

@psusi: Hab ich nicht. Ich habe verschiedene Fehler bekommen, einschließlich "Dateisystem voll". Wenn sich das in den letzten zwei oder drei Jahren geändert hat, wäre das eine gute Sache.

— Eric Towers

Ich habe neulich versucht, eine Datei in ein schreibgeschütztes ZFS-Dateisystem unter Linux zu verschieben. Der Fehler besagte ganz klar "Nur-Lese-Dateisystem".

— ein CVn

Nee; seit über 30 Jahren. Ein Schreibzugriff auf ein schreibgeschütztes fs gibt -EROFS zurück. Ein Write to a Full Fs gibt -ENOSPC zurück.

— Psusi

@psusi: Ich sehe, dass Sie in einem Fantasy-Universum leben, in dem Programmierer immer das Richtige tun, anstatt ihre eigenen Fehlermeldungen zu erfinden. Ich scheine dort nicht zu leben.

— Eric Towers