Problème d'espace libre

Le
sanao
Bonjour,

J'ai un problème assez étrange avec ma Mandrake 10 Official.

Sur une partition FAT32, lorsque je supprime un fichier avec Konqueror (je
n'ai pas essayé en utilisant rm), le fichier est bien supprimé, mais
l'espace libre de la partition reste inchangé. Le plus étrange est que cela
ne me le fait pas à chaque fois.

Pour que l'espace libre de la partition soit correctement recalculé, il faut
que je boot sous Windows 2000.

J'ai analysé la partition avec différents utilitaires (celui fournit avec
Windows 2000 et Norton Utilities) et il n'y a aucune erreur.

Si quelqu'un avait une idée.

Merci d'avance.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
thierry.rouillon
Le #1052146
sanao nous a gentiment écrit:

Bonjour,

J'ai un problème assez étrange avec ma Mandrake 10 Official.

Sur une partition FAT32, lorsque je supprime un fichier avec Konqueror (je
n'ai pas essayé en utilisant rm), le fichier est bien supprimé, mais
l'espace libre de la partition reste inchangé. Le plus étrange est que
cela ne me le fait pas à chaque fois.

Pour que l'espace libre de la partition soit correctement recalculé, il
faut que je boot sous Windows 2000.

J'ai analysé la partition avec différents utilitaires (celui fournit avec
Windows 2000 et Norton Utilities) et il n'y a aucune erreur.

Si quelqu'un avait une idée.

Merci d'avance.
Je ne connais pas cette version mais ne serait ce pas un problème de

rafraichissement d'ecran
--
Thierry de Champagne... l'adresse est fermée: Les bouteilles sont vides.

sanao
Le #1523995
Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran
Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir

l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le
fichier.

J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace
libre n'est pas correctement recalculé.

Le seul moyen de régler le problème est de redémarrer sous Windows. C'est
loin d'être pratique...

A+

françois
Le #1523992
sanao wrote:
Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran


Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir
l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le
fichier.

J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace
libre n'est pas correctement recalculé.

Le seul moyen de régler le problème est de redémarrer sous Windows. C'est
loin d'être pratique...

A+


Salut ,

ce n'est qu'une suggestion ,mais cela est peut-être du à
l'algo spécifique du noyau linux concernant l'ecriture et
la supression de fichiers différé :selon la charge de l'ordi
,mémoire et autre, ces deux actions peuvent être remis à
plus tard et c'est pour cela que tu as ce phénomène
(de plus il ne se reproduit pas à chaque fois).

Sur disquette par exemple ,lorsque tu fait une écriture (ou donc une
suppression ) tu peux t'aperçevoir que l'action n'est effectuée
que lors du démontage (tous ce qui est entrepris ne l'est qu'en mémoire
),ou en utilisant la commande sync (synchronisation)(man sync) ,
cela est pareil pour tous périphériques: dd et autres clé usb....


gaasmann
Le #1053692
"françois" IUwic.15621$
sanao wrote:

ce n'est qu'une suggestion ,mais cela est peut-être du à
l'algo spécifique du noyau linux concernant l'ecriture et
la supression de fichiers différé :selon la charge de l'ordi
,mémoire et autre, ces deux actions peuvent être remis à
plus tard et c'est pour cela que tu as ce phénomène
(de plus il ne se reproduit pas à chaque fois).



Si tu le peux, démonte puis remonte ta partition et vérifie à nouveau ton
espace disque pour en avoir le coeur net.

a+

--
Gaasmann

no_spam
Le #1053307
On Sat, 24 Apr 2004 16:49:44 +0000, françois wrote:

sanao wrote:
Je ne connais pas cette version mais ne serait ce pas un problème de
rafraichissement d'ecran


Cela ne vient pas du tout de KDE. Lorsque j'utilise la commande df pour voir
l'espace libre. Ce dernier n'a pas changé alors que j'ai bien supprimer le
fichier.

J'ai aussi essayé en utilisant la commande rm. Et une fois sur deux l'espace
libre n'est pas correctement recalculé.

Le seul moyen de régler le problème est de redémarrer sous Windows. C'est
loin d'être pratique...

A+


Salut ,

ce n'est qu'une suggestion ,mais cela est peut-être du à
l'algo spécifique du noyau linux concernant l'ecriture et
la supression de fichiers différé :selon la charge de l'ordi
,mémoire et autre, ces deux actions peuvent être remis à
plus tard et c'est pour cela que tu as ce phénomène
(de plus il ne se reproduit pas à chaque fois).


Les actions physiques sont différées mais le kernel sait que les
fichiers ont été supprimés et les statistiques du file-system ne sont
pas affectées par le système de cache.
Ce n'est donc pas celà qui intèrfère.
Pour s'en convaincre:
dd if=/dev/urandom of=/tmp/test count=xxx
df /tmp ; sync ; df /tmp
rm -f /tmp/test
df /tmp ; sync ; df /tmp
l'espace libre sera bien mis à jour avant les sync.

Par contre, si quelqu'un utilise les fichiers en question, ceux-ci
sont marqués effacés mais l'espace correspondant n'est libéré que
quand le fichier est fermé: sinon, l'utilisateur du fichier aurait
des erreurs alléatoires ou des donnnées incohérentes.
C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment
du rm.



françois
Le #1053304
no_spam wrote:

Bonjour ,

Les actions physiques sont différées mais le kernel sait que les
fichiers ont été supprimés et les statistiques du file-system ne sont
pas affectées par le système de cache.
Ce n'est donc pas celà qui intèrfère.
Pour s'en convaincre:
dd if=/dev/urandom of=/tmp/test count=xxx
df /tmp ; sync ; df /tmp
rm -f /tmp/test
df /tmp ; sync ; df /tmp
l'espace libre sera bien mis à jour avant les sync.


Pour ma part , merci pour la précision , c'était un peu vague .


Par contre, si quelqu'un utilise les fichiers en question, ceux-ci
sont marqués effacés mais l'espace correspondant n'est libéré que
quand le fichier est fermé: sinon, l'utilisateur du fichier aurait
des erreurs alléatoires ou des donnnées incohérentes.
C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment
du rm.


Donc dans le cas de Sanao le problème ne vient pas de là , à moins
qu'il ai ouvert ouvert le même fichier plusieurs fois (?).
Peut-être que le module fat est foireux , je ne pense pas non plus
,j'en ai pas entendu parlé (faut voir google).

no_spam
Le #1053302
On Sun, 25 Apr 2004 13:36:20 +0000, françois wrote:

no_spam wrote:

Par contre, si quelqu'un utilise les fichiers en question, ceux-ci
sont marqués effacés mais l'espace correspondant n'est libéré que
quand le fichier est fermé: sinon, l'utilisateur du fichier aurait
des erreurs alléatoires ou des donnnées incohérentes.
C'est le seul cas, je crois, ou l'espace n'est pas libéré au moment
du rm.


Donc dans le cas de Sanao le problème ne vient pas de là , à moins
qu'il ai ouvert ouvert le même fichier plusieurs fois (?).


Il suffit qu'il soit ouvert une fois, et pas encore fermé au moment
du rm...

Peut-être que le module fat est foireux , je ne pense pas non plus
,j'en ai pas entendu parlé (faut voir google).


C'est extrèmement peu probable: c'est un des file-system les plus
testés de Linux. A moins que ce ne soit pas un kernel standard et
que les patches appliqués soient la cause du bug...
Pour savoir, il faut tester avec un kernel officiel...


sanao
Le #1053907
Salut,

Après quelques test, j'ai enfin résolu le problème.

Voilà l'explication :
Les fichiers que je supprimais se trouvaient sur une partition et cette
partition était utilisée par MLdonkey, les fichiers étaient donc ouverts.
Le fait de les supprimer alors qu'ils étaient ouverts ne libérait donc pas
l'espace libre tant que les fichiers n'étaient pas fermés.

J'avais oublié de dire que les fichiers qui n'étaient vraiment supprimés
pouvaient réapparaitre au bout d'un certains temps dans la fenêtre de
Konqueror avec une taille de 0 octet. Je ne sais pas si c'est un problème
de Konqueror ou de Linux vu que je n'ai pas pensé à faire un ls. Maintenant
j'ai la flemme de refaire des tests pour trouver d'où vient le problème, ça
restera donc un mystère! ;-)

Quoiqu'il en soit, mon problème est maintenant réglé (MLdonkey ne partage
plus la partition). Merci à tous pour votre aide.

A+
Publicité
Poster une réponse
Anonyme