Debian, installation minimale, occupation du disque

Le
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.)

Merci d'avance pour vos éclaircissements.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #1883350
Fabien LE LEZ wrote in message
- 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
Le #1883349
On 11 Apr 2007 18:18:45 GMT, Nicolas George

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
Le #1883342
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...

Nicolas George
Le #1883340
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.

Nicolas George
Le #1883339
narberd wrote in message
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
Le #1883338
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 :

:~$ df -mT
Sys. de fich. Type 1M-blocs Occupé Disponible Capacité Monté sur
/dev/hda6 ext3 6249 3989 1943 68% /
tmpfs tmpfs 252 0 252 0% /lib/init/rw
udev tmpfs 10 1 10 1% /dev
tmpfs tmpfs 252 0 252 0% /dev/shm
/dev/hda8 ext3 16163 4289 11054 28% /home

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...


Nicolas George
Le #1883337
narberd wrote in message
32 Mo de différence seulement pour une partition de 16 Go. J'ai un plus
petit journal que vous?


dumpe2fs /dev/hda8 | grep 'Journal size:'

narberd
Le #1883332
narberd wrote in message
32 Mo de différence seulement pour une partition de 16 Go. J'ai un plus
petit journal que vous?


dumpe2fs /dev/hda8 | grep 'Journal size:'



:~$ sudo dumpe2fs /dev/hda8 | grep 'ournal'
dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem features: has_journal filetype needs_recovery sparse_super
Journal inode: 8
Journal backup: inode blocks
Taille du journal: 32M

C'est bien ça. Merci.
--
remplacez tele-deux par tele2 pour m'écrire...


Le chat de personne
Le #1883324
On Wed, 11 Apr 2007 20:15:12 +0200, Fabien LE LEZ
- 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 #1883318
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.

Publicité
Poster une réponse
Anonyme