J'observe des trucs qui me paraissent bizarres, sur ma machine (Linux).
J'ai plusieurs partitions sur mon disque dur, dont une en FAT32. Et je
vois ça :
$ mount
[...]
/dev/hda1 on /win type vfat (rw,iocharset=iso8859-15,umask=0,codepage=850)
$ df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
[...]
/dev/hda1 5,9G 5,3G 618M 90% /win
$ cd /win
$ du -hs
4,0G .
Comment se fait-il que df ne trouve pas la même taille que du ? Où est
passé le 1,3 Go de différence ?
J'ai fait les mêmes tests sous root, pour être sûr, et j'ai aussi recompté
"à la main" et à la louche la taille de /win, qui occuppe bien 4 Go
environ. J'ai envisagé des histoires de synchronisation pas encore faites,
mais un coup de sync n'a rien changé (d'ailleurs, ça fait très longtemps
que je n'ai rien écrit ou lu sur cette partition, donc je ne vois pas
pourquoi ça serait ça), tout comme 'df --sync'.
Du coup, comme df est instantané alors que du mouline un peu avant de
sortir le résultat, je ne vois plus qu'une seule explication : que df
utilise une sorte de base de données pour stocker les valeurs, et celle-ci
n'est pas à jour, mais je ne suis pas du tout convaincu...
Le man de df comme celui de du ne m'aident pas plus.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
J'observe des trucs qui me paraissent bizarres, sur ma machine (Linux). J'ai plusieurs partitions sur mon disque dur, dont une en FAT32. Et je vois ça :
$ mount [...] /dev/hda1 on /win type vfat (rw,iocharset=iso8859-15,umask=0,codepa ge…0) $ df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur [...] /dev/hda1 5,9G 5,3G 618M 90% /win $ cd /win $ du -hs 4,0G .
Comment se fait-il que df ne trouve pas la même taille que du ? Où est passé le 1,3 Go de différence ?
J'ai fait les mêmes tests sous root, pour être sûr, et j'ai aussi recompté "à la main" et à la louche la taille de /win, qui occuppe bien 4 Go environ. J'ai envisagé des histoires de synchronisation pas encore fa ites, mais un coup de sync n'a rien changé (d'ailleurs, ça fait très lo ngtemps que je n'ai rien écrit ou lu sur cette partition, donc je ne vois pas pourquoi ça serait ça), tout comme 'df --sync'.
Du coup, comme df est instantané alors que du mouline un peu avant de sortir le résultat, je ne vois plus qu'une seule explication : que df utilise une sorte de base de données pour stocker les valeurs, et cel le-ci n'est pas à jour, mais je ne suis pas du tout convaincu...
perdu
2 solutions
1: c ets juste aue tu a des process qui on ouvert des fichiers en ecriture et que tu a efface les fichiers, alors ce aui se passe c est les fichier sont encore dans le FS mais plus present dans la liste des fichier present, donc le du ne les vois pas alors que le df si.
2: en fat32, la taille des blocs etant assez gros, la taille reel d un fichier et sa taille physique sur le FS peut etre diffenretes de bcp (gerne 1 fichier de 16 Ko sur un GROS FS en FAT32 pourait faire 32 ou 64 Ko)
pour ca fait soous dos/windows chkdsk ca te donnera la taille des cluster et la taille perdu pour cela.
Le man de df comme celui de du ne m'aident pas plus.
Remi Moyen wrote:
Salut,
J'observe des trucs qui me paraissent bizarres, sur ma machine (Linux).
J'ai plusieurs partitions sur mon disque dur, dont une en FAT32. Et je
vois ça :
$ mount
[...]
/dev/hda1 on /win type vfat (rw,iocharset=iso8859-15,umask=0,codepa ge=850)
$ df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
[...]
/dev/hda1 5,9G 5,3G 618M 90% /win
$ cd /win
$ du -hs
4,0G .
Comment se fait-il que df ne trouve pas la même taille que du ? Où est
passé le 1,3 Go de différence ?
J'ai fait les mêmes tests sous root, pour être sûr, et j'ai aussi recompté
"à la main" et à la louche la taille de /win, qui occuppe bien 4 Go
environ. J'ai envisagé des histoires de synchronisation pas encore fa ites,
mais un coup de sync n'a rien changé (d'ailleurs, ça fait très lo ngtemps
que je n'ai rien écrit ou lu sur cette partition, donc je ne vois pas
pourquoi ça serait ça), tout comme 'df --sync'.
Du coup, comme df est instantané alors que du mouline un peu avant de
sortir le résultat, je ne vois plus qu'une seule explication : que df
utilise une sorte de base de données pour stocker les valeurs, et cel le-ci
n'est pas à jour, mais je ne suis pas du tout convaincu...
perdu
2 solutions
1:
c ets juste aue tu a des process qui on ouvert des fichiers en ecriture
et que tu a efface les fichiers, alors ce aui se passe c est les fichier
sont encore dans le FS mais plus present dans la liste des fichier
present, donc le du ne les vois pas alors que le df si.
2:
en fat32, la taille des blocs etant assez gros, la taille reel d un
fichier et sa taille physique sur le FS peut etre diffenretes de bcp
(gerne 1 fichier de 16 Ko sur un GROS FS en FAT32 pourait faire 32 ou 64 Ko)
pour ca fait soous dos/windows chkdsk ca te donnera la taille des
cluster et la taille perdu pour cela.
Le man de df comme celui de du ne m'aident pas plus.
J'observe des trucs qui me paraissent bizarres, sur ma machine (Linux). J'ai plusieurs partitions sur mon disque dur, dont une en FAT32. Et je vois ça :
$ mount [...] /dev/hda1 on /win type vfat (rw,iocharset=iso8859-15,umask=0,codepa ge…0) $ df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur [...] /dev/hda1 5,9G 5,3G 618M 90% /win $ cd /win $ du -hs 4,0G .
Comment se fait-il que df ne trouve pas la même taille que du ? Où est passé le 1,3 Go de différence ?
J'ai fait les mêmes tests sous root, pour être sûr, et j'ai aussi recompté "à la main" et à la louche la taille de /win, qui occuppe bien 4 Go environ. J'ai envisagé des histoires de synchronisation pas encore fa ites, mais un coup de sync n'a rien changé (d'ailleurs, ça fait très lo ngtemps que je n'ai rien écrit ou lu sur cette partition, donc je ne vois pas pourquoi ça serait ça), tout comme 'df --sync'.
Du coup, comme df est instantané alors que du mouline un peu avant de sortir le résultat, je ne vois plus qu'une seule explication : que df utilise une sorte de base de données pour stocker les valeurs, et cel le-ci n'est pas à jour, mais je ne suis pas du tout convaincu...
perdu
2 solutions
1: c ets juste aue tu a des process qui on ouvert des fichiers en ecriture et que tu a efface les fichiers, alors ce aui se passe c est les fichier sont encore dans le FS mais plus present dans la liste des fichier present, donc le du ne les vois pas alors que le df si.
2: en fat32, la taille des blocs etant assez gros, la taille reel d un fichier et sa taille physique sur le FS peut etre diffenretes de bcp (gerne 1 fichier de 16 Ko sur un GROS FS en FAT32 pourait faire 32 ou 64 Ko)
pour ca fait soous dos/windows chkdsk ca te donnera la taille des cluster et la taille perdu pour cela.
Le man de df comme celui de du ne m'aident pas plus.
Remi Moyen
On Mon, 20 Oct 2003, [Sauron De Mordor] wrote:
Comment se fait-il que df ne trouve pas la même taille que du ? Où est passé le 1,3 Go de différence ? [...]
Du coup, comme df est instantané alors que du mouline un peu avant de sortir le résultat, je ne vois plus qu'une seule explication : que df utilise une sorte de base de données pour stocker les valeurs, et celle-ci n'est pas à jour, mais je ne suis pas du tout convaincu...
perdu
Damned. :-)
1: c ets juste aue tu a des process qui on ouvert des fichiers en ecriture et que tu a efface les fichiers, alors ce aui se passe c est les fichier sont encore dans le FS mais plus present dans la liste des fichier present, donc le du ne les vois pas alors que le df si.
J'y ai pensé, après avoir vu un post dans un ML (de Debian, je crois), de quelqu'un qui avait le même problème que moi, et pour lequel ça venait de ce que tu indiques. Mais dans mon cas, non. D'une part, aucun programme n'a de raisons de tourner en utilisant cette partition, et d'autre part, un lsof comme un tour dans /proc ne donne rien. Bon, j'ai pu rater quelque chose, bien sûr.
2: en fat32, la taille des blocs etant assez gros, la taille reel d un fichier et sa taille physique sur le FS peut etre diffenretes de bcp (gerne 1 fichier de 16 Ko sur un GROS FS en FAT32 pourait faire 32 ou 64 Ko)
pour ca fait soous dos/windows chkdsk ca te donnera la taille des cluster et la taille perdu pour cela.
Bon, je ne vais pas rebooter ma machine rien que pour ça, donc je teste sous VMWare. Au passage, il est possible que ce soit VMWare qui ait foutu le bazar dès le début, je ne sais pas.
Résultat : windows reconnait environ 4 Go d'occuppés, comme du. Le chkdsk me dit : Windows has checked the filesystem and found no problem. 6 132 832 KB total disk space. 541 120 KB in 461 hidden files. 6 956 KB in 1 427 folders. 3 570 712 KB in 29 708 files. 2 014 040 KB are available.
4 096 bytes in each allocation unit. 1 533 208 total allocation units on disk. 503 510 allocation units available on disk.
Il voit donc lui aussi un disque rempli par 4 Go (3,5 Go de données, et 0,5 Go de fichiers cachés, en l'occurence la mémoire virtuelle, je crois).
Pas mieux... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Mon, 20 Oct 2003, [Sauron De Mordor] wrote:
Comment se fait-il que df ne trouve pas la même taille que du ? Où est
passé le 1,3 Go de différence ?
[...]
Du coup, comme df est instantané alors que du mouline un peu avant de
sortir le résultat, je ne vois plus qu'une seule explication : que df
utilise une sorte de base de données pour stocker les valeurs, et celle-ci
n'est pas à jour, mais je ne suis pas du tout convaincu...
perdu
Damned. :-)
1:
c ets juste aue tu a des process qui on ouvert des fichiers en ecriture
et que tu a efface les fichiers, alors ce aui se passe c est les fichier
sont encore dans le FS mais plus present dans la liste des fichier
present, donc le du ne les vois pas alors que le df si.
J'y ai pensé, après avoir vu un post dans un ML (de Debian, je crois), de
quelqu'un qui avait le même problème que moi, et pour lequel ça venait de
ce que tu indiques. Mais dans mon cas, non. D'une part, aucun programme
n'a de raisons de tourner en utilisant cette partition, et d'autre part,
un lsof comme un tour dans /proc ne donne rien. Bon, j'ai pu rater quelque
chose, bien sûr.
2:
en fat32, la taille des blocs etant assez gros, la taille reel d un
fichier et sa taille physique sur le FS peut etre diffenretes de bcp
(gerne 1 fichier de 16 Ko sur un GROS FS en FAT32 pourait faire 32 ou 64 Ko)
pour ca fait soous dos/windows chkdsk ca te donnera la taille des
cluster et la taille perdu pour cela.
Bon, je ne vais pas rebooter ma machine rien que pour ça, donc je teste
sous VMWare. Au passage, il est possible que ce soit VMWare qui ait foutu
le bazar dès le début, je ne sais pas.
Résultat : windows reconnait environ 4 Go d'occuppés, comme du.
Le chkdsk me dit :
Windows has checked the filesystem and found no problem.
6 132 832 KB total disk space.
541 120 KB in 461 hidden files.
6 956 KB in 1 427 folders.
3 570 712 KB in 29 708 files.
2 014 040 KB are available.
4 096 bytes in each allocation unit.
1 533 208 total allocation units on disk.
503 510 allocation units available on disk.
Il voit donc lui aussi un disque rempli par 4 Go (3,5 Go de données, et
0,5 Go de fichiers cachés, en l'occurence la mémoire virtuelle, je crois).
Pas mieux...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Comment se fait-il que df ne trouve pas la même taille que du ? Où est passé le 1,3 Go de différence ? [...]
Du coup, comme df est instantané alors que du mouline un peu avant de sortir le résultat, je ne vois plus qu'une seule explication : que df utilise une sorte de base de données pour stocker les valeurs, et celle-ci n'est pas à jour, mais je ne suis pas du tout convaincu...
perdu
Damned. :-)
1: c ets juste aue tu a des process qui on ouvert des fichiers en ecriture et que tu a efface les fichiers, alors ce aui se passe c est les fichier sont encore dans le FS mais plus present dans la liste des fichier present, donc le du ne les vois pas alors que le df si.
J'y ai pensé, après avoir vu un post dans un ML (de Debian, je crois), de quelqu'un qui avait le même problème que moi, et pour lequel ça venait de ce que tu indiques. Mais dans mon cas, non. D'une part, aucun programme n'a de raisons de tourner en utilisant cette partition, et d'autre part, un lsof comme un tour dans /proc ne donne rien. Bon, j'ai pu rater quelque chose, bien sûr.
2: en fat32, la taille des blocs etant assez gros, la taille reel d un fichier et sa taille physique sur le FS peut etre diffenretes de bcp (gerne 1 fichier de 16 Ko sur un GROS FS en FAT32 pourait faire 32 ou 64 Ko)
pour ca fait soous dos/windows chkdsk ca te donnera la taille des cluster et la taille perdu pour cela.
Bon, je ne vais pas rebooter ma machine rien que pour ça, donc je teste sous VMWare. Au passage, il est possible que ce soit VMWare qui ait foutu le bazar dès le début, je ne sais pas.
Résultat : windows reconnait environ 4 Go d'occuppés, comme du. Le chkdsk me dit : Windows has checked the filesystem and found no problem. 6 132 832 KB total disk space. 541 120 KB in 461 hidden files. 6 956 KB in 1 427 folders. 3 570 712 KB in 29 708 files. 2 014 040 KB are available.
4 096 bytes in each allocation unit. 1 533 208 total allocation units on disk. 503 510 allocation units available on disk.
Il voit donc lui aussi un disque rempli par 4 Go (3,5 Go de données, et 0,5 Go de fichiers cachés, en l'occurence la mémoire virtuelle, je crois).
Pas mieux... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Stephane Chazelas
Ça serait pas du à des fichiers cachés de NTFS ?
(Notez que "du" retourne le disk usage, donc l'argument de la taille des blocs n'est pas valide).
-- Stéphane [adresse-réelle: "Stephane.Chazelas" arobase "free.fr"] et hop, une signature plus longue que le texte, faudra que je trouve une autre technique anti-spam...
Ça serait pas du à des fichiers cachés de NTFS ?
(Notez que "du" retourne le disk usage, donc l'argument de la
taille des blocs n'est pas valide).
--
Stéphane [adresse-réelle: "Stephane.Chazelas" arobase "free.fr"]
et hop, une signature plus longue que le texte, faudra que je
trouve une autre technique anti-spam...
(Notez que "du" retourne le disk usage, donc l'argument de la taille des blocs n'est pas valide).
-- Stéphane [adresse-réelle: "Stephane.Chazelas" arobase "free.fr"] et hop, une signature plus longue que le texte, faudra que je trouve une autre technique anti-spam...
Stephane Chazelas
Note que df utilise statfs(2) qui lit les informations du super-bloc. Ensuite, pour calculer l'espace utilisé, il fait "total - free". Maintenant, peut-etre que pour du fat32, de l'espace peut etre à la fois non-utilisé et non-libre, va savoir.
Note que df utilise statfs(2) qui lit les informations du
super-bloc. Ensuite, pour calculer l'espace utilisé, il fait
"total - free". Maintenant, peut-etre que pour du fat32, de
l'espace peut etre à la fois non-utilisé et non-libre, va
savoir.
Note que df utilise statfs(2) qui lit les informations du super-bloc. Ensuite, pour calculer l'espace utilisé, il fait "total - free". Maintenant, peut-etre que pour du fat32, de l'espace peut etre à la fois non-utilisé et non-libre, va savoir.
Non, cette partition est en FAT32, pas en NTFS (je le disais dans mon premier message, je crois).
(Notez que "du" retourne le disk usage, donc l'argument de la taille des blocs n'est pas valide).
Ben comme ça, on en est sûr, au moins...
[et dans ton autre message : ]
Note que df utilise statfs(2) qui lit les informations du super-bloc. Ensuite, pour calculer l'espace utilisé, il fait "total - free". Maintenant, peut-etre que pour du fat32, de l'espace peut etre à la fois non-utilisé et non-libre, va savoir.
Mouais. C'est bizarre, quand même. -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Mon, 20 Oct 2003, Stephane Chazelas wrote:
Ça serait pas du à des fichiers cachés de NTFS ?
Non, cette partition est en FAT32, pas en NTFS (je le disais dans mon
premier message, je crois).
(Notez que "du" retourne le disk usage, donc l'argument de la
taille des blocs n'est pas valide).
Ben comme ça, on en est sûr, au moins...
[et dans ton autre message : ]
Note que df utilise statfs(2) qui lit les informations du
super-bloc. Ensuite, pour calculer l'espace utilisé, il fait
"total - free". Maintenant, peut-etre que pour du fat32, de
l'espace peut etre à la fois non-utilisé et non-libre, va
savoir.
Mouais. C'est bizarre, quand même.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Non, cette partition est en FAT32, pas en NTFS (je le disais dans mon premier message, je crois).
(Notez que "du" retourne le disk usage, donc l'argument de la taille des blocs n'est pas valide).
Ben comme ça, on en est sûr, au moins...
[et dans ton autre message : ]
Note que df utilise statfs(2) qui lit les informations du super-bloc. Ensuite, pour calculer l'espace utilisé, il fait "total - free". Maintenant, peut-etre que pour du fat32, de l'espace peut etre à la fois non-utilisé et non-libre, va savoir.
Mouais. C'est bizarre, quand même. -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
