Debian, installation minimale, occupation du disque
21 réponses
Fabien LE LEZ
Bonjour,
Je viens d'installer une Debian sur une machine. J'ai décoché tous les
composants optionnels, et effectivement, il n'y a pas grand-chose
d'installé -- même pas wget.
Pourtant, le truc de base prend 272 Mo... ou peut-être 417 Mo.
D'après du, la dizaine de milliers de fichiers présents sur la
partition (hors /proc) prend 272 Mo ; d'après df, 417 Mo sont
utilisés.
Histoire d'avoir le coeur net, j'ai fait le même test avec un live CD,
et j'obtiens les mêmes résultats.
D'où mes questions :
- Est-il normal qu'il y ait une telle différence entre ce
qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de
fichiers sur le disque ?
- Est-il normal qu'une installation "pseudo-minimale" (y'a quand
même bash, apt-get, et quelques autres trucs de base) prenne autant de
place ?
- Accessoirement, quelle est l'occupation disque minimale qu'on
puisse atteindre, tout en ayant la possibilité de rajouter ce qu'on
veut au fur et à mesure ? (I.e. il faut que apt-get [ou équivalent --
yum par exemple], et la couche réseau, fonctionnent.)
- Est-il normal qu'il y ait une telle différence entre ce qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de fichiers sur le disque ?
Quel filesystem ? Quelle taille totale du disque ?
Fabien LE LEZ wrote in message
<tn8q131dfrjketlifck92oh8ho8sv6h26d@4ax.com>:
- Est-il normal qu'il y ait une telle différence entre ce
qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de
fichiers sur le disque ?
Quel filesystem ? Quelle taille totale du disque ?
- Est-il normal qu'il y ait une telle différence entre ce qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de fichiers sur le disque ?
Quel filesystem ? Quelle taille totale du disque ?
Fabien LE LEZ
On 11 Apr 2007 18:18:45 GMT, Nicolas George <nicolas$:
Quel filesystem ?
ext3
Quelle taille totale du disque ?
Le disque fait 8 Go (une partition / de 7,6 Go, et une partition swap de 400 Mo).
On 11 Apr 2007 18:18:45 GMT, Nicolas George
<nicolas$george@salle-s.org>:
Quel filesystem ?
ext3
Quelle taille totale du disque ?
Le disque fait 8 Go (une partition / de 7,6 Go, et une partition swap
de 400 Mo).
On 11 Apr 2007 18:18:45 GMT, Nicolas George <nicolas$:
Quel filesystem ?
ext3
Quelle taille totale du disque ?
Le disque fait 8 Go (une partition / de 7,6 Go, et une partition swap de 400 Mo).
narberd
Bonjour, ...
D'où mes questions : - Est-il normal qu'il y ait une telle différence entre ce qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de fichiers sur le disque ? man du me dit que :
--apparent-size afficher les volumes effectifs, au lieu de l'espace occupé sur le disque. Même si le volume effectif est habituellement plus faible, il peut être plus important en raison de trous dans des fichiers « discontinus », de fragmentation, de blocs indirects ou pour d'autres raisons similaires.
Pour une installation fraîche cela peut paraître paradoxal, mais combien de fichiers temporaires sont crées pendant tout ce temps là? Cela peut-être une explication de la défragmentation.
Sur mon système installé depuis presque 3 mois, mon répertoire home contient 4210 Mo de fichiers tandis que df me dit que la partition /home contient 4242 Mo de fichiers. Le comportement de ton installation ne semble pas anormal de ce côté là. Cependant, mes chiffres semblent beaucoup plus raisonnables que les tiens. ext3 est sensé ne pas créer de défragmentation. Mais fait-il ça d'un seul coup? Il faudrait voir après plusieurs jours d'utilisation, peut-être même plusieurs démarrage si la différence persiste ou si elle s'amenuise.
- Est-il normal qu'une installation "pseudo-minimale" (y'a quand même bash, apt-get, et quelques autres trucs de base) prenne autant de place ? - Accessoirement, quelle est l'occupation disque minimale qu'on puisse atteindre, tout en ayant la possibilité de rajouter ce qu'on veut au fur et à mesure ? (I.e. il faut que apt-get [ou équivalent -- yum par exemple], et la couche réseau, fonctionnent.)
Pour la beauté de la manipulation, je rallume mon vieux, très vieux PC équipé d'un écran IBM PS2 en couleur, de 128 Mo de RAM et de quelques Go de disque. Sa Debian n'est pas totalement minimaliste car il y a les sources du noyaux et ses résidus de compilations. Voici les résultats en Mo, après moult moulinements : partitions /home /usr total (/ compris) df -m 172 925 1496 (calcul) du -cPsm 164 917 1599 (du -cPsm /)
résultat inattendu s'il en est.
on recommence autrement, avec le nombre de blocs de 1K : partitions /home /usr total (/ compris) df 175312 946774 1530223 (calcul) du -cPs 167086 938548 1636567 (du -cPs /)
j'sais pas quoi dire...
Pour finir, /usr/src occupe 434 Mo, en se basant sur les résultats de df et en virant /usr/src de mes calculs, nous obtenons une config de base de 1165 Mo. dpkg -l me rappelle qu'il y a quand même Apache, PHP, ssh, exim4, gcc, snort, quelques Prolog et autres Lisp.
Merci d'avance pour vos éclaircissements.
PS : as-tu fait un apt-get clean avant tes mesures? Pas moi... Je descends ainsi à 860 Mo. Et c'est toujours assez gros.
-- remplacez tele-deux par tele2 pour m'écrire...
Bonjour,
...
D'où mes questions :
- Est-il normal qu'il y ait une telle différence entre ce
qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de
fichiers sur le disque ?
man du me dit que :
--apparent-size
afficher les volumes effectifs, au lieu de l'espace
occupé sur le
disque. Même si le volume effectif est habituellement
plus faible,
il peut être plus important en raison de trous dans
des fichiers
« discontinus », de fragmentation, de blocs
indirects ou pour
d'autres raisons similaires.
Pour une installation fraîche cela peut paraître paradoxal, mais combien
de fichiers temporaires sont crées pendant tout ce temps là? Cela
peut-être une explication de la défragmentation.
Sur mon système installé depuis presque 3 mois, mon répertoire home
contient 4210 Mo de fichiers tandis que df me dit que la partition /home
contient 4242 Mo de fichiers. Le comportement de ton installation ne
semble pas anormal de ce côté là. Cependant, mes chiffres semblent
beaucoup plus raisonnables que les tiens. ext3 est sensé ne pas créer de
défragmentation. Mais fait-il ça d'un seul coup? Il faudrait voir après
plusieurs jours d'utilisation, peut-être même plusieurs démarrage si la
différence persiste ou si elle s'amenuise.
- Est-il normal qu'une installation "pseudo-minimale" (y'a quand
même bash, apt-get, et quelques autres trucs de base) prenne autant de
place ?
- Accessoirement, quelle est l'occupation disque minimale qu'on
puisse atteindre, tout en ayant la possibilité de rajouter ce qu'on
veut au fur et à mesure ? (I.e. il faut que apt-get [ou équivalent --
yum par exemple], et la couche réseau, fonctionnent.)
Pour la beauté de la manipulation, je rallume mon vieux, très vieux PC
équipé d'un écran IBM PS2 en couleur, de 128 Mo de RAM et de quelques Go
de disque. Sa Debian n'est pas totalement minimaliste car il y a les
sources du noyaux et ses résidus de compilations. Voici les résultats en
Mo, après moult moulinements :
partitions /home /usr total (/ compris)
df -m 172 925 1496 (calcul)
du -cPsm 164 917 1599 (du -cPsm /)
résultat inattendu s'il en est.
on recommence autrement, avec le nombre de blocs de 1K :
partitions /home /usr total (/ compris)
df 175312 946774 1530223 (calcul)
du -cPs 167086 938548 1636567 (du -cPs /)
j'sais pas quoi dire...
Pour finir, /usr/src occupe 434 Mo, en se basant sur les résultats de df
et en virant /usr/src de mes calculs, nous obtenons une config de base
de 1165 Mo. dpkg -l me rappelle qu'il y a quand même Apache, PHP, ssh,
exim4, gcc, snort, quelques Prolog et autres Lisp.
Merci d'avance pour vos éclaircissements.
PS : as-tu fait un apt-get clean avant tes mesures? Pas moi... Je
descends ainsi à 860 Mo. Et c'est toujours assez gros.
D'où mes questions : - Est-il normal qu'il y ait une telle différence entre ce qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de fichiers sur le disque ? man du me dit que :
--apparent-size afficher les volumes effectifs, au lieu de l'espace occupé sur le disque. Même si le volume effectif est habituellement plus faible, il peut être plus important en raison de trous dans des fichiers « discontinus », de fragmentation, de blocs indirects ou pour d'autres raisons similaires.
Pour une installation fraîche cela peut paraître paradoxal, mais combien de fichiers temporaires sont crées pendant tout ce temps là? Cela peut-être une explication de la défragmentation.
Sur mon système installé depuis presque 3 mois, mon répertoire home contient 4210 Mo de fichiers tandis que df me dit que la partition /home contient 4242 Mo de fichiers. Le comportement de ton installation ne semble pas anormal de ce côté là. Cependant, mes chiffres semblent beaucoup plus raisonnables que les tiens. ext3 est sensé ne pas créer de défragmentation. Mais fait-il ça d'un seul coup? Il faudrait voir après plusieurs jours d'utilisation, peut-être même plusieurs démarrage si la différence persiste ou si elle s'amenuise.
- Est-il normal qu'une installation "pseudo-minimale" (y'a quand même bash, apt-get, et quelques autres trucs de base) prenne autant de place ? - Accessoirement, quelle est l'occupation disque minimale qu'on puisse atteindre, tout en ayant la possibilité de rajouter ce qu'on veut au fur et à mesure ? (I.e. il faut que apt-get [ou équivalent -- yum par exemple], et la couche réseau, fonctionnent.)
Pour la beauté de la manipulation, je rallume mon vieux, très vieux PC équipé d'un écran IBM PS2 en couleur, de 128 Mo de RAM et de quelques Go de disque. Sa Debian n'est pas totalement minimaliste car il y a les sources du noyaux et ses résidus de compilations. Voici les résultats en Mo, après moult moulinements : partitions /home /usr total (/ compris) df -m 172 925 1496 (calcul) du -cPsm 164 917 1599 (du -cPsm /)
résultat inattendu s'il en est.
on recommence autrement, avec le nombre de blocs de 1K : partitions /home /usr total (/ compris) df 175312 946774 1530223 (calcul) du -cPs 167086 938548 1636567 (du -cPs /)
j'sais pas quoi dire...
Pour finir, /usr/src occupe 434 Mo, en se basant sur les résultats de df et en virant /usr/src de mes calculs, nous obtenons une config de base de 1165 Mo. dpkg -l me rappelle qu'il y a quand même Apache, PHP, ssh, exim4, gcc, snort, quelques Prolog et autres Lisp.
Merci d'avance pour vos éclaircissements.
PS : as-tu fait un apt-get clean avant tes mesures? Pas moi... Je descends ainsi à 860 Mo. Et c'est toujours assez gros.
-- remplacez tele-deux par tele2 pour m'écrire...
Nicolas George
Fabien LE LEZ wrote in message :
ext3
Le disque fait 8 Go (une partition / de 7,6 Go, et une partition swap de 400 Mo).
she-seel /tmp $ dd if=/dev/zero bs=1M seekv00 count=0 of=dummy 0+0 records in 0+0 records out 0 bytes (0 B) copied, 1.1e-05 seconds, 0.0 kB/s she-seel /tmp $ /sbin/mkfs.ext3 dummy <snip> Creating journal (32768 blocks): done <snip> she-seel /tmp $ sudo mount -o loop dummy /mnt/ she-seel /tmp $ df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /tmp/dummy 7660168 148296 7122752 3% /mnt
En d'autres termes, sur un filesystem absolument vierge, du rapporte presque 150 Mo occupés. Ça correspond assez précisément à la différence que tu observes.
On a probablement l'explication pour 128 de ces méga-octets dans les messages de mkfs.ext3 : le journal (32768 blocs de 4 ko). Pour la vingtaine qui manque, je ne sais pas trop.
Fabien LE LEZ wrote in message
<cq9q139mb53uts61jpcnorljue732o427n@4ax.com>:
ext3
Le disque fait 8 Go (une partition / de 7,6 Go, et une partition swap
de 400 Mo).
she-seel /tmp $ dd if=/dev/zero bs=1M seekv00 count=0 of=dummy
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.1e-05 seconds, 0.0 kB/s
she-seel /tmp $ /sbin/mkfs.ext3 dummy
<snip>
Creating journal (32768 blocks): done
<snip>
she-seel /tmp $ sudo mount -o loop dummy /mnt/
she-seel /tmp $ df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/tmp/dummy 7660168 148296 7122752 3% /mnt
En d'autres termes, sur un filesystem absolument vierge, du rapporte presque
150 Mo occupés. Ça correspond assez précisément à la différence que tu
observes.
On a probablement l'explication pour 128 de ces méga-octets dans les
messages de mkfs.ext3 : le journal (32768 blocs de 4 ko). Pour la vingtaine
qui manque, je ne sais pas trop.
Le disque fait 8 Go (une partition / de 7,6 Go, et une partition swap de 400 Mo).
she-seel /tmp $ dd if=/dev/zero bs=1M seekv00 count=0 of=dummy 0+0 records in 0+0 records out 0 bytes (0 B) copied, 1.1e-05 seconds, 0.0 kB/s she-seel /tmp $ /sbin/mkfs.ext3 dummy <snip> Creating journal (32768 blocks): done <snip> she-seel /tmp $ sudo mount -o loop dummy /mnt/ she-seel /tmp $ df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /tmp/dummy 7660168 148296 7122752 3% /mnt
En d'autres termes, sur un filesystem absolument vierge, du rapporte presque 150 Mo occupés. Ça correspond assez précisément à la différence que tu observes.
On a probablement l'explication pour 128 de ces méga-octets dans les messages de mkfs.ext3 : le journal (32768 blocs de 4 ko). Pour la vingtaine qui manque, je ne sais pas trop.
Nicolas George
narberd wrote in message <QQbTh.221$:
man du me dit que : --apparent-size afficher les volumes effectifs, au lieu de l'espace occupé sur le disque. Même si le volume effectif est habituellement plus faible, il peut être plus important en raison de trous dans des fichiers « discontinus », de fragmentation, de blocs indirects ou pour d'autres raisons similaires.
Pour une installation fraîche cela peut paraître paradoxal, mais combien de fichiers temporaires sont crées pendant tout ce temps là? Cela peut-être une explication de la défragmentation.
Non, ce n'est pas ça. du et df mesurent bien la même chose quand cette option n'est pas mise. Et, à vrai dire, il est très rarement utile de la mettre.
D'ailleurs, je ne vois pas comment la fragmentation interne (qui n'est pas la même chose que la fragmentation externe, qui est ce que tu évoques avec tes fichiers temporaires) ou les blocs indirects pourraient donner une taille du fichier supérieure à l'espace occupé, au contraire. La seule raison possible à ma connaissance est les sparce files.
narberd wrote in message <QQbTh.221$Qa.210@nntpserver.swip.net>:
man du me dit que :
--apparent-size
afficher les volumes effectifs, au lieu de l'espace
occupé sur le
disque. Même si le volume effectif est habituellement
plus faible,
il peut être plus important en raison de trous dans
des fichiers
« discontinus », de fragmentation, de blocs
indirects ou pour
d'autres raisons similaires.
Pour une installation fraîche cela peut paraître paradoxal, mais combien
de fichiers temporaires sont crées pendant tout ce temps là? Cela
peut-être une explication de la défragmentation.
Non, ce n'est pas ça. du et df mesurent bien la même chose quand cette
option n'est pas mise. Et, à vrai dire, il est très rarement utile de la
mettre.
D'ailleurs, je ne vois pas comment la fragmentation interne (qui n'est pas
la même chose que la fragmentation externe, qui est ce que tu évoques avec
tes fichiers temporaires) ou les blocs indirects pourraient donner une
taille du fichier supérieure à l'espace occupé, au contraire. La seule
raison possible à ma connaissance est les sparce files.
man du me dit que : --apparent-size afficher les volumes effectifs, au lieu de l'espace occupé sur le disque. Même si le volume effectif est habituellement plus faible, il peut être plus important en raison de trous dans des fichiers « discontinus », de fragmentation, de blocs indirects ou pour d'autres raisons similaires.
Pour une installation fraîche cela peut paraître paradoxal, mais combien de fichiers temporaires sont crées pendant tout ce temps là? Cela peut-être une explication de la défragmentation.
Non, ce n'est pas ça. du et df mesurent bien la même chose quand cette option n'est pas mise. Et, à vrai dire, il est très rarement utile de la mettre.
D'ailleurs, je ne vois pas comment la fragmentation interne (qui n'est pas la même chose que la fragmentation externe, qui est ce que tu évoques avec tes fichiers temporaires) ou les blocs indirects pourraient donner une taille du fichier supérieure à l'espace occupé, au contraire. La seule raison possible à ma connaissance est les sparce files.
narberd
Fabien LE LEZ wrote in message :
ext3
...
On a probablement l'explication pour 128 de ces méga-octets dans les messages de mkfs.ext3 : le journal (32768 blocs de 4 ko). Pour la vingtaine qui manque, je ne sais pas trop.
Et pourquoi je n'ai pas tant de différences entre les deux? Voici un df de mon Mac :
et le du sur home : :~$ du -cPsm /home 4257 /home 4257 total
32 Mo de différence seulement pour une partition de 16 Go. J'ai un plus petit journal que vous? -- remplacez tele-deux par tele2 pour m'écrire...
Fabien LE LEZ wrote in message
<cq9q139mb53uts61jpcnorljue732o427n@4ax.com>:
ext3
...
On a probablement l'explication pour 128 de ces méga-octets dans les
messages de mkfs.ext3 : le journal (32768 blocs de 4 ko). Pour la vingtaine
qui manque, je ne sais pas trop.
Et pourquoi je n'ai pas tant de différences entre les deux? Voici un df
de mon Mac :
On a probablement l'explication pour 128 de ces méga-octets dans les messages de mkfs.ext3 : le journal (32768 blocs de 4 ko). Pour la vingtaine qui manque, je ne sais pas trop.
Et pourquoi je n'ai pas tant de différences entre les deux? Voici un df de mon Mac :
C'est bien ça. Merci. -- remplacez tele-deux par tele2 pour m'écrire...
Le chat de personne
On Wed, 11 Apr 2007 20:15:12 +0200, Fabien LE LEZ wrote:
- Est-il normal qu'il y ait une telle différence entre ce qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de fichiers sur le disque ?
Si je puis me permettre je vais m'incruster ici pour une autre question :
Comment connaitre la taille reel de l'espace disque disponible ? Je remarque souvnet des differences d'indication en fonction du gestionnaire de fichier que j'utilise. D''apres ce que je constate c'est du a la facon dont on considere les fichiers avec lien sybolique. (je pense que ca doit etre ca) Par exemple /home fais chez moi 40Go Je sais que je ne peux pas avoir plus. Par contre si je demande a konqueror ou krusader de me donner la taille du repertoire /home cela arrive qu'il fasse plus que 40Go (parfois de plusieurs Go) C'est ca que je n'arrive pas a bien comprendre avec linux et ce probleme m'embete car j'ai parfois du mal a trouver les fichiers volumineux que je dois supprimer.
voila merci
On Wed, 11 Apr 2007 20:15:12 +0200, Fabien LE LEZ <gramster@gramster.com> wrote:
- Est-il normal qu'il y ait une telle différence entre ce
qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de
fichiers sur le disque ?
Si je puis me permettre je vais m'incruster ici pour une autre question :
Comment connaitre la taille reel de l'espace disque disponible ?
Je remarque souvnet des differences d'indication en fonction du gestionnaire de fichier que j'utilise.
D''apres ce que je constate c'est du a la facon dont on considere les fichiers avec lien sybolique. (je pense que ca doit etre ca)
Par exemple /home fais chez moi 40Go Je sais que je ne peux pas avoir plus.
Par contre si je demande a konqueror ou krusader de me donner la taille du repertoire /home cela arrive qu'il fasse plus que 40Go (parfois de plusieurs Go)
C'est ca que je n'arrive pas a bien comprendre avec linux et ce probleme m'embete car j'ai parfois du mal a trouver les fichiers volumineux que je dois supprimer.
On Wed, 11 Apr 2007 20:15:12 +0200, Fabien LE LEZ wrote:
- Est-il normal qu'il y ait une telle différence entre ce qu'indique du et ce qu'indique df, alors qu'il y a relativement peu de fichiers sur le disque ?
Si je puis me permettre je vais m'incruster ici pour une autre question :
Comment connaitre la taille reel de l'espace disque disponible ? Je remarque souvnet des differences d'indication en fonction du gestionnaire de fichier que j'utilise. D''apres ce que je constate c'est du a la facon dont on considere les fichiers avec lien sybolique. (je pense que ca doit etre ca) Par exemple /home fais chez moi 40Go Je sais que je ne peux pas avoir plus. Par contre si je demande a konqueror ou krusader de me donner la taille du repertoire /home cela arrive qu'il fasse plus que 40Go (parfois de plusieurs Go) C'est ca que je n'arrive pas a bien comprendre avec linux et ce probleme m'embete car j'ai parfois du mal a trouver les fichiers volumineux que je dois supprimer.
voila merci
Blaise Potard
Le Thu, 12 Apr 2007 14:57:36 +0200, Le chat de personne a écrit:
Comment connaitre la taille reel de l'espace disque disponible ?
df ? Par exemple : df -Ph | tail -n +2 | awk '{print $1,$4}'
Tu peux aussi utiliser du, ça marche aussi.
Je remarque souvnet des differences d'indication en fonction du gestionnaire de fichier que j'utilise. D''apres ce que je constate c'est du a la facon dont on considere les fichiers avec lien sybolique. (je pense que ca doit etre ca)
Je pense plutôt que ce sont des fichiers avec pleins de zero dedans. Il ne faut pas confondre la _taille_ d'un fichier et l'espace disque qu'il occupe. Lorsqu'il vient d'être crée, un fichier peut faire plusieurs Go, mais n'occuper que quelques ko sur le disque. Si tu utilises des logiciels de P2P comme bittorrent ou emule, c'est courant : les explorateurs graphiques t'indiqueront la _taille_ du fichier (ou les sommes des tailles pour les répertoires), mais en réalité il pourra n'occuper que quelques ko sur le disque tant que les blocs n'auront pas été écrits.
C'est ca que je n'arrive pas a bien comprendre avec linux et ce probleme m'embete car j'ai parfois du mal a trouver les fichiers volumineux que je dois supprimer.
find ? Par exemple, pour afficher les fichiers de taille supérieur à 10M : find ! -type d -size +10M -printf "%kk %pn" | sort -rn
Tu pourrais d'ailleurs avoir des surprises, vu que le -size utilisera la taille du fichier, alors que le -printf ... affichera l'espace occupé. Je précise que cette commande a plein de défauts, mais a priori ça devrait t'aller.
Le Thu, 12 Apr 2007 14:57:36 +0200, Le chat de personne a écrit:
Comment connaitre la taille reel de l'espace disque disponible ?
df ?
Par exemple :
df -Ph | tail -n +2 | awk '{print $1,$4}'
Tu peux aussi utiliser du, ça marche aussi.
Je remarque souvnet des differences d'indication en fonction du
gestionnaire de fichier que j'utilise. D''apres ce que je constate c'est
du a la facon dont on considere les fichiers avec lien sybolique. (je
pense que ca doit etre ca)
Je pense plutôt que ce sont des fichiers avec pleins de zero dedans. Il ne
faut pas confondre la _taille_ d'un fichier et l'espace disque qu'il
occupe. Lorsqu'il vient d'être crée, un fichier peut faire plusieurs Go,
mais n'occuper que quelques ko sur le disque. Si tu utilises des logiciels
de P2P comme bittorrent ou emule, c'est courant : les explorateurs
graphiques t'indiqueront la _taille_ du fichier (ou les sommes des tailles
pour les répertoires), mais en réalité il pourra n'occuper que quelques ko
sur le disque tant que les blocs n'auront pas été écrits.
C'est ca que je n'arrive pas a bien comprendre avec linux et ce probleme
m'embete car j'ai parfois du mal a trouver les fichiers volumineux que
je dois supprimer.
find ? Par exemple, pour afficher les fichiers de taille supérieur à 10M :
find ! -type d -size +10M -printf "%kk %pn" | sort -rn
Tu pourrais d'ailleurs avoir des surprises, vu que le -size utilisera la
taille du fichier, alors que le -printf ... affichera l'espace occupé. Je
précise que cette commande a plein de défauts, mais a priori ça devrait
t'aller.
Le Thu, 12 Apr 2007 14:57:36 +0200, Le chat de personne a écrit:
Comment connaitre la taille reel de l'espace disque disponible ?
df ? Par exemple : df -Ph | tail -n +2 | awk '{print $1,$4}'
Tu peux aussi utiliser du, ça marche aussi.
Je remarque souvnet des differences d'indication en fonction du gestionnaire de fichier que j'utilise. D''apres ce que je constate c'est du a la facon dont on considere les fichiers avec lien sybolique. (je pense que ca doit etre ca)
Je pense plutôt que ce sont des fichiers avec pleins de zero dedans. Il ne faut pas confondre la _taille_ d'un fichier et l'espace disque qu'il occupe. Lorsqu'il vient d'être crée, un fichier peut faire plusieurs Go, mais n'occuper que quelques ko sur le disque. Si tu utilises des logiciels de P2P comme bittorrent ou emule, c'est courant : les explorateurs graphiques t'indiqueront la _taille_ du fichier (ou les sommes des tailles pour les répertoires), mais en réalité il pourra n'occuper que quelques ko sur le disque tant que les blocs n'auront pas été écrits.
C'est ca que je n'arrive pas a bien comprendre avec linux et ce probleme m'embete car j'ai parfois du mal a trouver les fichiers volumineux que je dois supprimer.
find ? Par exemple, pour afficher les fichiers de taille supérieur à 10M : find ! -type d -size +10M -printf "%kk %pn" | sort -rn
Tu pourrais d'ailleurs avoir des surprises, vu que le -size utilisera la taille du fichier, alors que le -printf ... affichera l'espace occupé. Je précise que cette commande a plein de défauts, mais a priori ça devrait t'aller.
