Salut,
j'ai un problème très chiant sur une partition ext3, je ne sais pas où est partie ma mémoire libre et comment la récupérer
 
j'explique :
 
du -hscD *   ==>   870M    total
df -h              ==>   /dev/sda6             1,6G  1,5G  1,1M 100% /mnt/e
 
je n'ai que 870M de fichiers sur la partition de 1.6G mais linux ne me laisse plus rien y écrire.
 
A l'aide, je craque.
 
pium

lsof | grep deleted

2781:gconfd-2   4888 pouet   13wW  REG        8,5      697    272390 /tmp/gconfd-pouet/lock/0t1222795622ut45718u500p4888r1284684207k3215266136 (deleted)
 
c'est quoi cette commande ?
qu'est-ce qu'il fait quand il supprime ?

pour info /tmp/ n'est pas sur la meme partition
et aussi j'ai rebooté, mais rien n'y change...

t'as des fichiers cachés en .

c'est à ca que j'ai pensé en premier
'du' regarde aussi les fichiers commenceant par un .
 
sérieux il lui arrive quoi à cette partition ? est-ce possible que ce soit un pb de fragmentation ? (meme si je sais qu'en theorie ce n'est pas possible)

Un cas envisageable :  
Tu as un point de montage sur un dossier qui contient des données. Le fait que ce montage soit "monté", cela cache à 'du' une partie.

Comme ça à première vue, dans ce genre de cas, je vois encore plusieurs autres possibilités :
 
- un ou des processus n'ont pas correctement libéré des inodes (relancer ou tuer le(s) processus responsable(s) solutionne en général le problème) ou il n'y a plus d'inodes de disponible sur la partition ;
 
- le pourcentage de blocs réservés sur la partition fait que tu as atteint l'espace maximum alloué pour les processus non-privilégiés (userland) ;
 
- une gestion des quotas est en place et la limite utilisateur a été atteinte ;
 
- le système de fichier de la partition est corrompu.
 
 
La fragmentation n'a rien à voir avec l'espace disque, mais avec la façon dont sont organisés les blocs sur le FS (blocs non-contigus pour un même ensemble de données) ; donc il y a 99.9% de probabilités que ça ne vient pas de là
 
Pour tenter de résoudre ton problème, ces commandes sont tes alliées : df -i /dev/sda6 (% d'occupation d'inodes), dumpe2fs -h /dev/sda6 (toutes les infos utiles sur le FS), mount (options de montage), tune2fs et e2fsck pour modifier/réparer le FS si nécessaire (consulte les manpages pour les détails sur les actions possibles).
 
Parallèlement, en faisant une utilisation combinée des commandes lsof, ls -lah et du -csh, tu devrais pouvoir traquer sans problème les fichiers impliqués dans ce problème de place.

Malheureusement non, aucun repertoire de montage sur cette partition, mais bien vu.
 
 

Bien possible mais comment faire alors, car meme quand je reboot rien n'y fait. Et je pense avoir trouvé qui fait ca. Je code du gros sur cette partition, et quand je compile en debug (uniquement en debug), je perd 200Mo sans pouvoir deviner où il vont. Et je ne parle pas de lancer mon programme, juste de compiler. Comment dire à GCC de rendre ma place ?!
 

hum peut etre aussi => fsck.ext3 c'est bien ca ?
 
 
ok j'essaie de jouer avec ces commandes et je repasse par là.
 
MERCI !

ca s'en vient : e2fsck m'a corrigé tout ca, en effet il a trouvé plein de couilles de inodes.......
 
Mais alors pourquoi gcc me fait ca en debug, c'est un peu relou....
gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)
 
c'est assez chiant d'en installer une version plus récente jme rappelle avoir essayé une fois et j'avais galéré sans résultat...