«Il n'y a plus d'espace sur l'appareil», df montre un écart

15

Il y a quelques heures, ma partition racine s'est remplie, j'en ai retiré des fichiers et df rapporte:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             183G  174G     0 100% /

Il devrait donc y avoir 9 Go gratuits, mais les rapports de disponibilité 0 et l'utilisation sont toujours à 100%.

J'ai testé en tant que root, par exemple

# echo test >a ; cat a
test

cela fonctionne comme prévu; cependant, en tant qu'utilisateur normal, j'obtiens toujours l'erreur:

$ echo test >a ; cat a
bash: echo: write error: No space left on device

Le répertoire personnel racine où j'ai effectué le test positif et mon répertoire personnel se trouvent sur la même partition. L'entrée fstab est:

/dev/hda1 / ext3 noatime,defaults,errors=remount-ro 0 1

linux

— marque
source

34

La plupart des systèmes de classement réservent un certain pourcentage pour root, vous pouvez donc toujours vous connecter en tant que root et résoudre les problèmes d'espace disque. Il s'agit généralement de 5%. 9 Go représentent environ 5% de 183 Go, donc cela aurait du sens. Vous pouvez voir combien est réservé en utilisant tune2fs:

# tune2fs -l /dev/sda1 | grep -i reserved
Reserved block count:     936488
Reserved GDT blocks:      1019
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

Vous pouvez le modifier en utilisant

# tune2fs -m 3 /dev/sda1
tune2fs 1.41.9 (22-Aug-2009)
Setting reserved blocks percentage to 3% (561893 blocks)

Sur les gros disques modernes, 5% est probablement un peu excessif, et vous souhaiterez probablement le réduire. Vous ne voulez pas le mettre à zéro.

— David Pashley
source

1

Je ne peux pas croire que je ne le savais pas. Je ferais mieux de ne pas dire depuis combien de temps j'utilise Linux maintenant ...

— marquez

@nfm Hé, je fais l'administration de base de Linux sur les box domestiques depuis des années et je n'en ai jamais entendu parler. +1 pour une excellente information :-)

— Topher Fangio

5

im avec bob, essayez df -i, si vous avez un tas de crontabs de sortie malades par exemple, votre répertoire / var / spool / clientmqueue / peut être rempli

— CDATA
source

3

Jetez également un œil à INODES. Dans une installation "vanille", si vous avez beaucoup de petits fichiers, ils peuvent consommer des inodes, mais pas d'espace. Vous verrez que vous avez de l'espace disponible, mais comme vos inodes sont pleins, vous ne pourrez pas utiliser cet espace.

— Bob Rivers
source

3

La plupart des unités modernes ont un très grand nombre d'inodes même sur de petits systèmes de fichiers. C'est parfois un problème, mais étant donné que l'utilisateur est capable de créer le fichier c, il est peu probable qu'il s'agisse d'un problème d'inode. (les entrées de répertoire nécessitent des inodes même si elles ne nécessitent pas d'espace).

— chris

2

"Par défaut, chaque système de fichiers sous Unix a un espace réservé pour le superutilisateur (root). Cela signifie qu'aucun utilisateur Unix ordinaire ne peut remplir votre système de fichiers jusqu'à 100%, et qu'il aura donc toujours suffisamment d'espace libre pour continuer à fonctionner normalement. "

De: http://www.unixtutorial.org/commands/tune2fs/

— Dave P.
source

1

Une autre chose à vérifier est de voir s'il y a des fichiers ouverts sur ce système de fichiers (en particulier les journaux). La suppression de fichiers n'effacera pas l'espace sur le disque tant que le fichier n'est pas fermé.

— Chris Anderson
source

0

Je parierais 1 $ que Clyde a la réponse. Un processus a un fichier ouvert sur cet appareil. Sous Linux, le fichier n'est pas réellement supprimé jusqu'à ce que le processus le maintenant ouvert le lâche.

Je commencerais par: lsof | grep hda1

— Greeblesnort
source