[Résolu]incohérence d'espace disque disponible

Bonjour à tous,

J’ai un problème que je ne comprends pas. voila:
J’ai un serveur, virtualisé sous vmware, avec un espace disque total de 4Go. Voici un petit df -h :
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1 677M 100M 543M 16% /
tmpfs 253M 0 253M 0% /lib/init/rw
udev 10M 72K 10M 1% /dev
tmpfs 253M 0 253M 0% /dev/shm
/dev/sda9 293M 42M 237M 15% /home
/dev/sda8 206M 5,4M 190M 3% /tmp
/dev/sda5 888M 734M 109M 88% /usr
/dev/sda10 1,2G 610M 489M 56% /var

J’ai donc relativement de la place, or debian me dit que je n’ai plus de place sous /var! Exemple d’un simple touch :
machinexx:/# touch /var/test.txt
touch: ne peut faire un touch sur `/var/test.txt’: Aucun espace disponible sur le périphérique

C’est un serveur de supervision, et c’est assez embêtant je dois dire. J’ai beau purger (apt-get clean, localepureges, …) mais il reste tout de même quasi 500Mo!

Voila, si quelqu’un à une idée, un complément d’information, je suis preneur car je ne sais pas, c’est hors de moi.

Merci à vous!

Que donne
cat /proc/mounts

Ca ne serait pas un disque virtuel sda stocké dans un filesystem à trou qui serait posé sur une partition réelle du systême host qui, elle, est vraiment pleine ?

Mattotop décrit une situation originale, mais je doute un peu qu’elle puisse provoquer ce genre de message d’erreur. Il me semble que le logiciel émulant le disque dur ne pourrait générer qu’une erreur de lecture/écriture lors de l’accès à un secteur qui ne peut être alloué faute de place sur le système de fichier parent.

D’autre part, le manque de blocs libres n’empêche pas de créer un fichier vide avec touch. Par contre le manque d’inodes libres provoque exactement ce message. Il faudrait vérifier sda10 avec fsck -vfn.

merci des réponses,

En effet il y a un manque d’inodes libres.
http://img266.imageshack.us/img266/1135/screenfsckdr6.png

Donc la raison serait qu’il y a trop de (petits) fichiers sur ma partition, … Est-ce que la seule solution serait d’augmenter la taille de ma partition en sachant que j’aurai une taille utile faible ? Je pourrai recréer une partition en redéfinissant une taille de blocks plus petite… D’autres solution ?

sur des partitions de petite taille, il est préférable d’adapter le ration octets/inodes avec l’option -i de mkfs.ext3.
Voir le man mkfs.ext3.
Voir aussi le fichier /etc/mke2fs.conf

small = {
	blocksize = 1024
	inode_size = 128
	inode_ratio = 4096

sur des partitions de petite taille, il est préférable d’adapter le ratio octets/inodes avec l’option -i de mkfs.ext3.
Voir le man mkfs.ext3.
Voir aussi le fichier /etc/mke2fs.conf

small = {
	blocksize = 1024
	inode_size = 128
	inode_ratio = 4096

[/quote][quote=“skoobs”]Donc la raison serait qu’il y a trop de (petits) fichiers sur ma partition,[/quote]
On dirait bien. Ce sont des fichiers utiles ou il n’y aurait pas un peu de ménage à faire ?

La taille de la partition ou des blocs n’a rien à voir, du moins pas directement. C’est le nombre d’inodes (en gros 1 inode=1 fichier ou répertoire), défini à la création du système de fichiers, qui est insuffisant. Si tu ne peux pas faire du ménage, je ne vois pas d’autre solution que de changer de partition ou recréer le système de fichier avec un plus grand nombre d’inodes comme indiqué par cepcasa. Comme ça efface les données, il faudra les sauvegarder puis les restaurer.

Malheureusement, je ne peux faire de ménage.
Je vais recréer une partition, définir un nombre d’inodes plus important. C’est du virtuel, donc je vais rajouter un peu d’espace disque et le tour est joué.

Je vous tiens au courant tout de même!

Bon, du coup j’aimerai bien avoir une partition bien taillée.
En sachant que la taille utile vaut environ 1/2 du nombre d’inodes.

Si je mets un ratio d’octets par inode de 8192, au lieu de 4096 par défaut, c’est bon ?

Hop la, je crois que c’est 16384 octets par inode par défaut. Donc si je mets 8192, celà me fait un bon ratio!

Et bien voila, problème résolu. Nouvelle partition, avec 8192 en bytes-per-inode.

df- h :
/dev/sda1 677M 131M 512M 21% /
tmpfs 253M 0 253M 0% /lib/init/rw
udev 10M 60K 10M 1% /dev
tmpfs 253M 0 253M 0% /dev/shm
/dev/sda9 394M 42M 332M 12% /home
/dev/sda8 228M 5,6M 211M 3% /tmp
/dev/sda5 1,9G 1,2G 635M 66% /usr
/dev/sdb1 3,9G 711M 3,0G 19% /var

df -ih :
/dev/sda1 173K 11K 162K 7% /
tmpfs 64K 2 64K 1% /lib/init/rw
udev 64K 407 63K 1% /dev
tmpfs 64K 1 64K 1% /dev/shm
/dev/sda9 54K 316 54K 1% /home
/dev/sda8 59K 16 59K 1% /tmp
/dev/sda5 231K 77K 155K 34% /usr
/dev/sdb1 512K 80K 433K 16% /var

Merci pour vos solutions!

je ne comprends pas tes calculs.
Si tu donne une taille de 8000 bytes par inodes, tu auras moins d’inodes qu’en lui donnant une taille de 1024 bytes.

Pour le vérifier :

dumpe2fs -h /dev/ton_fs |grep -i inode

puis mkfs.ext3 -m1 -i 1024 /dev/ton_fs et encore le dumpe2fs -h ou tune2fs -l

Bien sûr mkfs va supprimer les données, inutile de le préciser.

Oui c’est exact. Mais par défaut (sans arguments) il mettait un nombre de 16384 octets/inode. Je l’ai donc juste divisé par 2 pour multiplier par 2 le nombre d’inodes.

Au début je pensais que la valeur par défaut était de 1024, mais en testant elle est de 16384 …
Je l’avais testé en positionnant plusieurs valeurs.

oui, si le fs a une taille de plus de 512 Mo comme précisé dans /etc/mke2fs.conf

Avec 1024 octets/inode et une taille de bloc de 4 Kio, ça fairait plus d’inodes que de blocs. Pas très utile, sauf si on compte avoir beaucoup de fichiers vides.

C’est pour celà maintenant j’ai une corrélation entre nombre de blocs et d’inodes, étant donné que j’ai beaucoup de petits fichiers. Il faut bien ajuster.

Avec 1024 octets/inode et une taille de bloc de 4 Kio, ça fairait plus d’inodes que de blocs. Pas très utile, sauf si on compte avoir beaucoup de fichiers vides.[/quote]
c’était une échelle, pas une valeure absolue à suivre à la lettre.
Pour le nombre d’inodes par rapport au nombre de blocs, ceci est précisé dans le man auquel j’avais conseillé de se référer.
Donc, pour résumer, sur un petit fs, il peut être raisonnable de mettre un rapport inodes/octets à 4096.