Impossible d'écrire sur le disque mais le disque n'est pas plein

J'utilise Ubuntu 12.04 et je ne peux écrire dans aucun fichier, même en tant que root, ni effectuer aucune autre opération nécessitant une écriture. De même, aucun processus nécessitant une écriture ne peut échouer. dfdit que j'ai beaucoup de place:

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

Tous les résultats que je trouve pour "ne peut pas écrire sur le disque" concernent des disques légitimement pleins. Je ne sais même pas par où commencer ici. Le problème est apparu de nulle part ce matin.

La dernière entrée du journal PHP est:

fail: Pas d'espace disponible sur le périphérique (28)

Vim dit:

Impossible d'ouvrir (fichier) en écriture

D'autres applications donnent des erreurs similaires.

Après avoir supprimé ~ 1 Go simplement pour être sûr, le problème persiste. J'ai aussi redémarré.

df -i dit

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 se réjouir
la source

Veuillez poster le résultat de "df -i".

EEAA

Vous avez raison, df -i dit 100%. Qu'est-ce que ça veut dire? Pourquoi serait-ce différent?

Felwithe

IIRC, trop de fichiers dans un seul répertoire auront des symptômes similaires, voire identiques. Ce qui est "trop" varie selon les systèmes de fichiers.

MSalters

Réponses:

Vous êtes à court d'inodes. Il est probable que vous ayez un répertoire quelque part avec de nombreux très petits fichiers.

EEAA
la source

Je voulais juste ajouter que je ne savais même pas que je rm pouvais échouer. Cela a été une éducation.

Felwithe

@felwithe, j'imagine que find . -name sess\* -exec rm {} +cela aurait fonctionné.

Carsten S

@felwithe Ce que d'autres ont suggéré. rm a probablement bien fonctionné, mais le shell a étendu le *glob à une trop grande quantité de données, et a corrigé avant même d’avoir invoqué rm.

un CVn

@CarstenS: Ou find . -name sess\* -deleteque je trouve plus facile à retenir et qui est généralement plus efficace.

MSalters

@Kaslai la limite il n'y a pas de RAM, mais la limite système ARG_MAX. La norme POSIX ne spécifie pas précisément comment les arguments de ligne de commande sont comparés à ARG_MAX, malheureusement. Certaines implémentations n'ont pas de limite et ne définissent donc pas ARG_MAX, mais ce n'est pas une option populaire car cela empêche trop de programmes de compiler.

James Youngman

Apparemment, le PO a une réponse à son problème particulier. Cependant, pour des raisons d'exhaustivité, les symptômes du PO peuvent également se produire si le système de fichiers a été réinstallé en lecture seule. Cela m'est arrivé avec une machine virtuelle Linux dont le stockage était sur un système de disques en cluster souffrant de rares pannes intermittentes. Parfois, les erreurs entraînent le remontage du (des) système (s) de fichiers en lecture seule. Le symptôme externe finalement observable était que plusieurs services ne répondaient plus à mesure que la RAM était remplie (avec des écritures sur disque non vidables).

À l'époque, la seule solution consistait à redémarrer le système (perte de tous les journaux non écrits qu'il y avait). Les tentatives de remontage de RW ont échoué. (Malheureusement, je ne me souviens pas des messages d'erreur renvoyés lors de ces tentatives de remontage.)

Donc, ..., pas le problème du PO, mais quelqu'un qui arrive sur cette page peut bénéficier de cette information.

Eric Towers
la source

Non en fait; lorsque le système de fichiers a été remonté en lecture seule, vous obtenez une erreur indiquant que le système de fichiers est en lecture seule et non pas saturé.

psusi

@ Psusi: Je n'ai pas. J'ai eu diverses erreurs, y compris "système de fichiers complet". Si cela a changé au cours des deux ou trois dernières années, ce serait une bonne chose.

Eric Towers

J'ai essayé de déplacer un fichier dans un système de fichiers ZFS en lecture seule sous Linux juste l'autre jour. L'erreur disait très clairement "système de fichiers en lecture seule".

un CVn

Nan; été ainsi depuis plus de 30 ans. Une écriture dans un fichier en lecture seule renvoie -EROFS; une écriture dans une fs complète renvoie -ENOSPC.

psusi

@ psusi: Je vois que vous vivez dans l'univers fantastique où les programmeurs font toujours ce qu'il faut au lieu de créer leurs propres messages d'erreur. Je ne semble pas y vivre.

Eric Towers