Voilà, dans une konsole, connecté root par le biais d'un su -, je lance la commande suite de commandes suivante :
root@lfs-David:/boot# df -h /boot
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hde1 16M 3,8M 11M 27% /boot
root@lfs-David:/boot# du -sch /boot
2,8M /boot
2,8M total
Y'a pas un truc qui vous choque ?
L'un m'indique qu'il y a 3.8Mo d'occupé, et l'autre 2.8Mo seulement. Je suis sur une LFS 5.1.1, kernel 2.4.20 et coreutils ver 5.2.1 ; le système de fichier utilisé est ext3, mais j'ai essayé sur une partition ntfs, l'écart entre les deux commandes est de 18 Go sur une partition de 34 Go !!!!!
Si quelqu'un a une explication rationnelle à ce problème, je suis preneur.
# 5% réservés à root ?
Posté par symoon . Évalué à 5.
tune2fs -m0 pour ne pas réserver de place pour root
ou -mX avec X le pourcentage
Après concernant ntfs, à mon avis cela peut être :
- la fragmentation du système de fichier
- le fait qu'une partition ntfs contienne un autre système de fichier (ce n'est pas très clair, mais on s'en rend compte lors du redimensionnement d'une partition ntfs : il faut d'abord redimensionner le contenu (affiché par du), puis le contenant (/dev/hdX))
[^] # Re: 5% réservés à root ?
Posté par Gyro Gearllose . Évalué à 3.
Pour le coup du ntfs, en effet, la fragmentation pourrait être une piste, mais pour ça, il faudrait que je redémarre mon vieux windows2000... Depuis le temps, je me demande si il fonctionnera encore.
En tout cas, c'est une idée intéressante qu'il va falloir que je creuse, car j'ai quand même 20Go qui sont indiqués comme pris par df alors qu'ils sont théoriquement libres par du....
[^] # Re: 5% réservés à root ?
Posté par Maillequeule . Évalué à 4.
Si par hasard un programme sature une partition (/var, /tmp, / ou autre) et empèche alors la machine de remplir son rôle, l'utilisateur root pourra toujours se connecter et avoir un espace de travail suffisant pour travailler à régler le problème.
Celà sous-entend que le processus fautif ne tourne pas avec les droits root bien sûr ...
Il est vrai que ces 5%, avec les capacités actuelles, necessite de revoir le chiffre à la baisse (pas forcément à zéro non plus), car on y laisse vite des Go ...
M
[^] # Re: 5% réservés à root ?
Posté par Jllc . Évalué à 4.
Ca laisse de la place à l'utilisateur root, mais aussi à tous les programmes tournant sous ce compte, c'est à dire bon nombre de composants du système, des démons importants.
[^] # Re: 5% réservés à root ?
Posté par Stephen Amar . Évalué à 1.
cette espace est reservé au root : imagine que ta plein d'utilisateurs sur ta box et que ton disque dur est rempli. Cette espace sert au root pour arranger tout ca ...
Mais bon si tu est le seul utilisateur....
[^] # Re: 5% réservés à root ?
Posté par Jllc . Évalué à 1.
Mais cette marge n'influence à priori pas la mesure de l'espace libre ou occupé (à confirmer quand même).
[^] # Re: 5% réservés à root ?
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[root@cmoi nzbget-0.1.2]# df
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda1 5,8G 4,9G 660M 89% /
/dev/hda6 49G 47G 1,3G 98% /home
[root@cmoi nzbget-0.1.2]# tune2fs -m1 /dev/hda1
tune2fs 1.35 (28-Feb-2004)
Setting reserved blocks percentage to 1 (15341 blocks)
[root@cmoi nzbget-0.1.2]# df
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda1 5,8G 4,9G 900M 85% /
/dev/hda6 49G 47G 1,3G 98% /home
[^] # Re: 5% réservés à root ?
Posté par HeKa . Évalué à 1.
Et si oui tune2fs n'étant pas valable quel commande utiliser ?
# Dans le même genre
Posté par Jllc . Évalué à 3.
Avec ces fichiers, j'ai observé le même problème de mesure de l'espace disque :
[jllc@Versa bochs]$ ls -lh winXP.img
-rw-r----- 1 jllc jllc 1,5G déc 30 19:33 winXP.img
[jllc@Versa bochs]$ du -hs winXP.img
288M winXP.img
Il y a aussi une incohérence avec la commande df (je ne l'indique pas ici, la partition est bien remplie par autre chose).
C'est probablement du à la structure particulière de ce fichier :
[jllc@Versa bochs]$ file winXP.img
winXP.img: x86 boot sector
[jllc@Versa bochs]$
Ta partition de boot contient peut être tout simplement des fichiers du même genre ?
[^] # Re: Dans le même genre
Posté par durandal . Évalué à 2.
anduril:~$ ls -lh img.fat
-rw-r--r-- 1 nicolas nicolas 121G 2004-11-19 19:09 img.fat
anduril:~$ du -hs img.fat
505M img.fat
Un fichier de 121 Go sur un disque de 20 Go, faut le faire ;)
Le type de fichier ne devrait pas influer comme ça sur sa taille apparente... C'est un gros bug.
[^] # Re: Dans le même genre
Posté par pierthi . Évalué à 2.
Mais le problème ici est plus étrange : "du" compabilise les blocs utilisés et vérifie l'unicité des inodes dans le total (liens physiques), le total devrait dans une certaine mesure correspondre avec la sortie de df. Genre chez moi :
# du /home -s
8,4G .
# df /home
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda7 24G 8,4G 16G 36% /home
La seule fois où j'ai eu une différence c'est avec une partition ext2 qui n'avait pas été fscheckée suite à plusieurs crash d'affilés.
[^] # Re: Dans le même genre
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
cf http://intgat.tigress.co.uk/rmy/uml/sparsify.html(...) et du --apparent-size
[^] # Re: Dans le même genre
Posté par Jllc . Évalué à 2.
Je comprends très bien ce qui se passe pour bochs. Mais pour le noyau Linux, ce fichier devrait être un fichier comme un autre, c'est à dire un gros paquet d'octets à la suite les uns des autres, n'ayant aucun sens particulier.
Quand je crée un fichier image de X méga-octets pour bochs, il fournit des indications de tête/cylindre/secteur correspondant pour y accéder depuis l'OS tournant avec l'émulateur, et tout se passe pour lui comme avec un disque dur réel. Il peut paraitre alors logique que ce fichier se remplisse donc progressivement comme un vrai disque dur. Mais c'est la taille réellement occupée que devrais affichier Linux. Que je sache, quant je créé un fichier texte ou une image, le fichier ne commence pas par faire XX ko ou XX Mo, il grandit au fur et à mesure que j'écris dedans.
Que la commande "ls" indique 40 octets pour la taille d'un fichier, pendant que la commande "du" indique 4 ko, cela s'explique simplement par la taille des unités de base d'un disque (le terme exacte m'échappe), la différence se trouvent dans l'espace inutilisé de cette unité (qui n'est pas partageable avec d'autres fichiers).
Mais l'inverse que l'on a ici, entre autres avec les images disques, d'où vient elle ??
[^] # Re: Dans le même genre
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
Tu as lu http://intgat.tigress.co.uk/rmy/uml/sparsify.html(...) donné plus haut ? Tu peux aussi lire http://www.aplawrence.com/Words/2003_10_04.html(...) ou http://www.ntfs.com/ntfs-sparse.htm(...)
[^] # Re: Dans le même genre
Posté par Gyro Gearllose . Évalué à 1.
Si j'ai bien tout compris, "df" indique la taille totale du fichier tandis que "du" indique l'espace occupé par le fichier sur le disque, ce qui, sur un filesystem ext2/3 ou ntfs est différent, alors que c'est la même information sur un filesystem fat ou fat32. J'ai bon ?
D'ailleurs, si on réfléchit un peu :
$man du
(...)
du - estimate file space usage
(...)
$man df
(...)
df - report filesystem disk space usage
(...)
C'est écrit dessus, comme le port salut !
M'enfin, sans savoir comment fonctionne le système de fichier, c'est pas une information facile a appréhender.
[^] # Re: Dans le même genre
Posté par daggett . Évalué à 4.
Par exemple, dans un système de fichier ext2 par défaut, les unités d'allocation font 1k; je viens de tester en créant un petit système de fichier de 1M (monté en loop) et en créant une centaine de fichiers qui contiennent tous seulement 1 caractère:
# mount
/tmp/block on /tmp/toto type ext2 (rw,loop=/dev/loop0)
# for i in {1..100}; do echo -n "A" > plop$i; done
# du
102 .
du me dit qu'il n'y a 102 octets de *données* (ah, les 2 en trop, je ne sais pas d'où ils viennent...)
et df me dit qu'il y a 102 *blocs* de 1k utilisés (1 par fichier), soit 102K
# df .
Filesystem 1K-blocks Used Available Use% Mounted on
/tmp/block 1003 102 850 11% /tmp/toto
# df -h .
Filesystem Size Used Avail Use% Mounted on
/tmp/block 1003K 102K 850K 11% /tmp/toto
bon, et puis sur de l'ext3, peut-être qu'il faut aussi prendre en compte la taille du journal ?..
[^] # Re: Dans le même genre
Posté par Gyro Gearllose . Évalué à 1.
J'ai compris beaucoup de choses grâce à tout ça. Pour le coup du journal, je ne sais trop que penser... Il me semble qu'il ne devrait pas figurer du tout dans les calculs puisque c'est un "fichier" un peu spécifique au système, tout comme la table des inodes et les répertoires...
Mais bon, c'est pas très important... Le reste de la question l'était bien plus !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.