Je ne comprends les resultats de du et df
Le
jerome moliere
--089e0160bab0b21a0204e738fee7
Content-Type: text/plain; charset=UTF-8
Bonjour a tous les poilus,
le probleme que j'ai n'est pas sous Debian mais je pense qu'il pourrait se
poser.
Il est sous Manjaro (archlinux)
J'ai un /home tres gros sur mon SSD de 512Go (382Go) en ext4
du -h et df -h si je les utilise ne me livrent pas une sortie coherente
blackbear@manjaro-laptop ~> df -h /home/
Filesystem Size Used Avail Use% Mounted on
/dev/sda9 381G 106G 256G 30% /home
le du -h me donne 106Go
mais ou sont passes les 19Go ?
un lsof |grep deleted me ramene peut etre 30 ou 40 Mo de fichiers flagges
deleted donc il en manque encoreC'est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer s'il perd de la place
ainsi
Je ne sais pas trop ou regarder pour en savoir plus ?
Il y a t'il une autre methode pour calculer l'espace dispo ?
Meme les arrondis n'expliquent pas de perdre 5% d'espace disque ainsi
J'hesitais a voir avec un dd monstrueux si je pouvais creer un fichier de
260Go!!!
Mais peut etre que cela depasse les limites du kernel ou du FS ?
bref je suis largue
merci a vous
PS:
j'ai aussi regarde dans le /proc et les resultats sont bien ceux ramenes
par lsof donc cette piste ne mene a rien
J.MOLIERE - Mentor/J
--089e0160bab0b21a0204e738fee7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir="ltr">Bonjour a tous les poilus,<div>le probleme que j'ai n&=
#39;est pas sous Debian mais je pense qu'il pourrait se poser.</div><di=
v>Il est sous Manjaro (archlinux)</div><div>J'ai un /home tres gros sur=
mon SSD de 512Go (382Go) en ext4 </div>
<div>du -h et df -h si je les utilise ne me livrent pas une sortie coherent=
e</div><div><br></div><div><div>blackbear@manjaro-laptop ~> df -h /home/=
</div><div>Filesystem Size Used Avail Use% Mounte=
d on</div><div>
/dev/sda9 381G 106G 256G 30% /home</=
div>
</div><div><br></div><div>le du -h me donne 106Go</div><div><br></div><div>=
mais ou sont passes les 19Go ?</div><div>un lsof |grep deleted me ramene pe=
ut etre 30 ou 40 Mo de fichiers flagges deleted donc il en manque encore=
C'est pas grave mais du coup je me pose beaucoup de questions car mon /=
pourrait vite saturer s'il perd de la place ainsi</div>
<div><br></div><div>Je ne sais pas trop ou regarder pour en savoir plus ?</=
div><div>Il y a t'il une autre methode pour calculer l'espace dispo=
?</div><div>Meme les arrondis n'expliquent pas de perdre 5% d'espa=
ce disque ainsi </div>
<div><br></div><div>J'hesitais a voir avec un dd monstrueux si je pouva=
is creer un fichier de 260Go!!!</div><div>Mais peut etre que cela dep=
asse les limites du kernel ou du FS ?</div><div>bref je suis largue </=
div><div>
<br></div><div>merci a vous</div><div>PS:</div><div>j'ai aussi regarde =
dans le /proc et les resultats sont bien ceux ramenes par lsof donc cette p=
iste ne mene a rien</div><div><br clear="all"><div><div dir="ltr">J.MOL=
IERE - Mentor/J<br>
<br></div></div>
</div></div>
--089e0160bab0b21a0204e738fee7--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAEGYFEJgDsvo0cMhSSUBApGy3Fp+fbwUO=m7Cvj2CdwTs9XMFw@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
Bonjour a tous les poilus,
le probleme que j'ai n'est pas sous Debian mais je pense qu'il pourrait se
poser.
Il est sous Manjaro (archlinux)
J'ai un /home tres gros sur mon SSD de 512Go (382Go) en ext4
du -h et df -h si je les utilise ne me livrent pas une sortie coherente
blackbear@manjaro-laptop ~> df -h /home/
Filesystem Size Used Avail Use% Mounted on
/dev/sda9 381G 106G 256G 30% /home
le du -h me donne 106Go
mais ou sont passes les 19Go ?
un lsof |grep deleted me ramene peut etre 30 ou 40 Mo de fichiers flagges
deleted donc il en manque encoreC'est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer s'il perd de la place
ainsi
Je ne sais pas trop ou regarder pour en savoir plus ?
Il y a t'il une autre methode pour calculer l'espace dispo ?
Meme les arrondis n'expliquent pas de perdre 5% d'espace disque ainsi
J'hesitais a voir avec un dd monstrueux si je pouvais creer un fichier de
260Go!!!
Mais peut etre que cela depasse les limites du kernel ou du FS ?
bref je suis largue
merci a vous
PS:
j'ai aussi regarde dans le /proc et les resultats sont bien ceux ramenes
par lsof donc cette piste ne mene a rien
J.MOLIERE - Mentor/J
--089e0160bab0b21a0204e738fee7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir="ltr">Bonjour a tous les poilus,<div>le probleme que j'ai n&=
#39;est pas sous Debian mais je pense qu'il pourrait se poser.</div><di=
v>Il est sous Manjaro (archlinux)</div><div>J'ai un /home tres gros sur=
mon SSD de 512Go (382Go) en ext4 </div>
<div>du -h et df -h si je les utilise ne me livrent pas une sortie coherent=
e</div><div><br></div><div><div>blackbear@manjaro-laptop ~> df -h /home/=
</div><div>Filesystem Size Used Avail Use% Mounte=
d on</div><div>
/dev/sda9 381G 106G 256G 30% /home</=
div>
</div><div><br></div><div>le du -h me donne 106Go</div><div><br></div><div>=
mais ou sont passes les 19Go ?</div><div>un lsof |grep deleted me ramene pe=
ut etre 30 ou 40 Mo de fichiers flagges deleted donc il en manque encore=
C'est pas grave mais du coup je me pose beaucoup de questions car mon /=
pourrait vite saturer s'il perd de la place ainsi</div>
<div><br></div><div>Je ne sais pas trop ou regarder pour en savoir plus ?</=
div><div>Il y a t'il une autre methode pour calculer l'espace dispo=
?</div><div>Meme les arrondis n'expliquent pas de perdre 5% d'espa=
ce disque ainsi </div>
<div><br></div><div>J'hesitais a voir avec un dd monstrueux si je pouva=
is creer un fichier de 260Go!!!</div><div>Mais peut etre que cela dep=
asse les limites du kernel ou du FS ?</div><div>bref je suis largue </=
div><div>
<br></div><div>merci a vous</div><div>PS:</div><div>j'ai aussi regarde =
dans le /proc et les resultats sont bien ceux ramenes par lsof donc cette p=
iste ne mene a rien</div><div><br clear="all"><div><div dir="ltr">J.MOL=
IERE - Mentor/J<br>
<br></div></div>
</div></div>
--089e0160bab0b21a0204e738fee7--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAEGYFEJgDsvo0cMhSSUBApGy3Fp+fbwUO=m7Cvj2CdwTs9XMFw@mail.gmail.com
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Bonsoir,
Quand tu crées un système de fichier sur un disque, un pourcentage de
l'espace de stockage est réservé à root (par défaut = 5%). Cet es pace dédié
permet de ne pas remplir complétement les disques, de permettre a certain e
applications critiques de continuer à sexécuter et donc d'éviter d e
bloquer le systéme. Cet espace de 5% dédié (modifiable avec la comman de
tune2fs) n'est pas visible comme étant de l'espace libre quand tu exécu te
la commande df.
Le 25 septembre 2013 19:57, jerome moliere écrit :
--
< Belaid >
--bcaec53f3959a472f804e739dc6e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div>Il est sous Manjaro (archlinux)</div><div>J'ai un /home tres gros sur mon SSD de 512Go (382Go) en ext4 </div>
<div>du -h et df -h si je les utilise ne me livrent pas une sortie coherent e</div><div><br></div><div><div> ~> df -h /home/ </div><div>Filesystem Size Used Avail Use% Mounted on</div><d iv>
/dev/sda9 381G 106G 256G 30% /home</div>
<div><br></div><div>J'hesitais a voir avec un dd monstrueux si je pouva is creer un fichier de 260Go!!!</div><div>Mais peut etre que cela depass e les limites du kernel ou du FS ?</div><div>bref je suis largue </div><d iv>
<br></div></div>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br>< Belaid >
</div>
--bcaec53f3959a472f804e739dc6e--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAFuS2bYM=XeL9+
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
peut être :) mais je t'avoue que j'ai relu encore la question => même
résultat :)
Le 25 septembre 2013 21:47, Johnny B
--
< Belaid >
--089e013d1eaac15eea04e73a9c1f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<br>
<br>
C'est juste les arguments que tu utilises pour ces 2 commandes qu i
diffèrent dans les résultats.<br>
<br>
Comme tu l a fait avec lsof on voit que certains process gardent
des fichiers supprimés ouverts, ce qui n'est pas visible par &q uot;du"<br>
<br>
De plus ces commandes calculent de différentes manières : <br>
<br>
df prends la plupart des ses infos depuis le superblock du
filesystem<br>
df inclu les fichiers ouverts<br>
<br>
du remonte l'info à un instant T c'est que tu vois maintena nt<br>
du n'inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d'autres différences<br>
<br>
Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est
plus significative dans l'instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense que
Belaïd n'a pas saisi ta question ;)<br>
<br>
<br>
Le 09/25/2013 09:00 PM, Belaïd a écrit :<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées un système de fichier sur un disque, un
pourcentage de l'espace de stockage est réservé à root (p ar
défaut = 5%). Cet espace dédié permet de ne pas remplir
complétement les disques, de permettre a certaine applications
critiques de continuer à sexécuter et donc d'éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la comman de
tune2fs) n'est pas visible comme étant de l'espace libre quand
tu exécute la commande df.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 19:57, jerome
moliere a écrit :<br>
<div dir="ltr">Bonjour a tous les poilus,
<div>le probleme que j'ai n'est pas sous Debian mais je
pense qu'il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J'ai un /home tres gros sur mon SSD de 512Go (382Go)
en ext4 </div>
<div>du -h et df -h si je les utilise ne me livrent pas
une sortie coherente</div>
<div><br>
</div>
<div>
<div> ~> df -h /home/</div>
<div>Filesystem Size Used Avail Use% Mounted on</div>
<div>
/dev/sda9 381G 106G 256G 30% /home</ div>
</div>
<div><br>
</div>
<div>le du -h me donne 106Go</div>
<div><br>
</div>
<div>mais ou sont passes les 19Go ?</div>
<div>un lsof |grep deleted me ramene peut etre 30 ou 40 Mo
de fichiers flagges deleted donc il en manque
encore...C'est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s'il perd de la place ainsi</div>
<div><br>
</div>
<div>Je ne sais pas trop ou regarder pour en savoir plus ?</d iv>
<div>Il y a t'il une autre methode pour calculer l'es pace
dispo ?</div>
<div>Meme les arrondis n'expliquent pas de perdre 5%
d'espace disque ainsi ...</div>
<div><br>
</div>
<div>J'hesitais a voir avec un dd monstrueux si je pouvai s
creer un fichier de 260Go!!!</div>
<div>Mais peut etre que cela depasse les limites du kernel
ou du FS ?</div>
<div>bref je suis largue </div>
<div>
<br>
</div>
<div>merci a vous</div>
<div>PS:</div>
<div>j'ai aussi regarde dans le /proc et les resultats
sont bien ceux ramenes par lsof donc cette piste ne mene
a rien</div>
<div><br clear="all">
<div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid >
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>< Belaid >
</div>
--089e013d1eaac15eea04e73a9c1f--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAFuS2bbVSTt0chH7j8ö=
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
A ouai c'est vrai ! j'étais sur du jack + glaçon ! Je vais voir c que c a va
donné avec une pinte ;-)
Le 25 sept. 2013 21:56, "Johnny B"
--089e010d86880e92ec04e73ab4d2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<p dir="ltr">A ouai c'est vrai ! j'étais sur du jack + glaçon ! Je vais voir c que ca va donné avec une pinte ;-)</p>
<div bgcolor="#FFFFFF" text="#000000">
<div>Relis avec une grosse pinte ca passera
mieux =)<br>
<br>
Le 09/25/2013 09:53 PM, Belaïd a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>peut être :) mais je t'avoue que j'ai relu encore la
question => même résultat :) <br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
a écrit :<br>
<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<br>
<br>
C'est juste les arguments que tu utilises pour ces 2
commandes qui diffèrent dans les résultats.<br>
<br>
Comme tu l a fait avec lsof on voit que certains process
gardent des fichiers supprimés ouverts, ce qui n'est pas
visible par "du"<br>
<br>
De plus ces commandes calculent de différentes manières
: <br>
<br>
df prends la plupart des ses infos depuis le superblock
du filesystem<br>
df inclu les fichiers ouverts<br>
<br>
du remonte l'info à un instant T c'est que tu voi s
maintenant<br>
du n'inclut pas les fichiers ouverts et ne se base pas
sur la taille des block<br>
<br>
et surement bien d'autres différences<br>
<br>
Ces 2 commandes sont très bonnes et "équivalentes& quot; mais
"du" est plus significative dans l'instant T< br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pens e
que Belaïd n'a pas saisi ta question ;)<br>
<br>
<br>
Le 09/25/2013 09:00 PM, Belaïd a écrit :<br>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées un système de fichier sur un
disque, un pourcentage de l'espace de stockage es t
réservé à root (par défaut = 5%). Cet espac e dédié
permet de ne pas remplir complétement les disques,
de permettre a certaine applications critiques de
continuer à sexécuter et donc d'éviter d e bloquer
le systéme. Cet espace de 5% dédié (modifiable
avec la commande tune2fs) n'est pas visible comme
étant de l'espace libre quand tu exécute la
commande df.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013
19:57, jerome moliere a écrit :<br>
<div dir="ltr">Bonjour a tous les poilus,
<div>le probleme que j'ai n'est pas sou s
Debian mais je pense qu'il pourrait se
poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J'ai un /home tres gros sur mon SSD de
512Go (382Go) en ext4 </div>
<div>du -h et df -h si je les utilise ne me
livrent pas une sortie coherente</div>
<div><br>
</div>
<div>
<div> ~> df -h
/home/</div>
<div>Filesystem Size Used Avail Use%
Mounted on</div>
<div> /dev/sda9 381G 106G 2 56G
30% /home</div>
</div>
<div><br>
</div>
<div>le du -h me donne 106Go</div>
<div><br>
</div>
<div>mais ou sont passes les 19Go ?</div>
<div>un lsof |grep deleted me ramene peut
etre 30 ou 40 Mo de fichiers flagges
deleted donc il en manque encore...C'est
pas grave mais du coup je me pose beaucoup
de questions car mon / pourrait vite
saturer s'il perd de la place ainsi</div>
<div><br>
</div>
<div>Je ne sais pas trop ou regarder pour en
savoir plus ?</div>
<div>Il y a t'il une autre methode pour
calculer l'espace dispo ?</div>
<div>Meme les arrondis n'expliquent pas de
perdre 5% d'espace disque ainsi ...</div>
<div><br>
</div>
<div>J'hesitais a voir avec un dd monstrueu x
si je pouvais creer un fichier de
260Go!!!</div>
<div>Mais peut etre que cela depasse les
limites du kernel ou du FS ?</div>
<div>bref je suis largue </div>
<div> <br>
</div>
<div>merci a vous</div>
<div>PS:</div>
<div>j'ai aussi regarde dans le /proc et le s
resultats sont bien ceux ramenes par lsof
donc cette piste ne mene a rien</div>
<div><br clear="all">
<div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid > </div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid >
</div>
</blockquote>
<br>
</div>
</blockquote></div>
--089e010d86880e92ec04e73ab4d2--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAFuS2bbqLX1A+
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Merci a Johnny et Belaid
mais si tu regardes la sortie de la commande df tu vois bien que :
106 + 256 cela ne fait pas 381 ....
et les fichiers reserved representent peanuts ..
d'ou ma question ou sont mes Go voles -)
J.MOLIERE - Mentor/J
Le 25 septembre 2013 21:47, Johnny B
--089e013d14ca95622804e73af8b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<br>
<br>
C'est juste les arguments que tu utilises pour ces 2 commandes qu i
diffèrent dans les résultats.<br>
<br>
Comme tu l a fait avec lsof on voit que certains process gardent
des fichiers supprimés ouverts, ce qui n'est pas visible par "du"<br>
<br>
De plus ces commandes calculent de différentes manières : < br>
<br>
df prends la plupart des ses infos depuis le superblock du
filesystem<br>
df inclu les fichiers ouverts<br>
<br>
du remonte l'info à un instant T c'est que tu vois maint enant<br>
du n'inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d'autres différences<br>
<br>
Ces 2 commandes sont très bonnes et "équivalentes" ; mais "du" est
plus significative dans l'instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense qu e
Belaïd n'a pas saisi ta question ;)<br>
<br>
<br>
Le 09/25/2013 09:00 PM, Belaïd a écrit :<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées un système de fichier sur un disque, un
pourcentage de l'espace de stockage est réservé à root (par
défaut = 5%). Cet espace dédié permet de ne pas re mplir
complétement les disques, de permettre a certaine applications
critiques de continuer à sâexécuter et donc d' ;éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la commande
tune2fs) n'est pas visible comme étant de l'espace lib re quand
tu exécute la commande df.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 19:57, jerome
moliere a écrit :<br>
<div dir="ltr">Bonjour a tous les poilus,
<div>le probleme que j'ai n'est pas sous Debian mais je
pense qu'il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J'ai un /home tres gros sur mon SSD de 512Go (382Go)
en ext4Â </div>
<div>du -h et df -h si je les utilise ne me livrent pas
une sortie coherente</div>
<div><br>
</div>
<div>
<div> ~> df -h /home/</div>
<div>Filesystem    Size  Used Avail U se% Mounted on</div>
<div>
/dev/sda9 Â Â Â 381G Â 106G Â 256G Â 30% /home</div>
</div>
<div><br>
</div>
<div>le du -h me donne 106Go</div>
<div><br>
</div>
<div>mais ou sont passes les 19Go ?</div>
<div>un lsof |grep deleted me ramene peut etre 30 ou 40 Mo
de fichiers flagges deleted donc il en manque
encore...C'est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s'il perd de la place ainsi</div>
<div><br>
</div>
<div>Je ne sais pas trop ou regarder pour en savoir plus ?</d iv>
<div>Il y a t'il une autre methode pour calculer l'es pace
dispo ?</div>
<div>Meme les arrondis n'expliquent pas de perdre 5%
d'espace disque ainsi ...</div>
<div><br>
</div>
<div>J'hesitais a voir avec un dd monstrueux si je pouvai s
creer un fichier de  260Go!!!</div>
<div>Mais peut etre que cela depasse les limites du kernel
ou du FS ?</div>
<div>bref je suis largue </div>
<div>
<br>
</div>
<div>merci a vous</div>
<div>PS:</div>
<div>j'ai aussi regarde dans le /proc et les resultats
sont bien ceux ramenes par lsof donc cette piste ne mene
a rien</div>
<div><br clear="all">
<div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid >
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>
--089e013d14ca95622804e73af8b0--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
5% de tes 381 ~ 19 volés => les 5% réservé a root selon ma vision.
Le 25 septembre 2013 22:19, jerome moliere écrit :
--
< Belaid >
--001a11c22634bac2cd04e73b0efd
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
106 + 256 cela ne fait pas 381 ....
<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<div><div class="h5"><br>
<br>
C'est juste les arguments que tu utilises pour ces 2 commandes qu i
diffèrent dans les résultats.<br>
<br>
Comme tu l a fait avec lsof on voit que certains process gardent
des fichiers supprimés ouverts, ce qui n'est pas visible par &q uot;du"<br>
<br>
De plus ces commandes calculent de différentes manières : <br>
<br>
df prends la plupart des ses infos depuis le superblock du
filesystem<br>
df inclu les fichiers ouverts<br>
<br>
du remonte l'info à un instant T c'est que tu vois maintena nt<br>
du n'inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d'autres différences<br>
<br>
Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est
plus significative dans l'instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense que
Belaïd n'a pas saisi ta question ;)<br>
<br>
<br>
Le 09/25/2013 09:00 PM, Belaïd a écrit :<br>
</div></div></div><div><div class="h5"><div><div>
<blockquote type="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées un système de fichier sur un disque, un
pourcentage de l'espace de stockage est réservé à root (p ar
défaut = 5%). Cet espace dédié permet de ne pas remplir
complétement les disques, de permettre a certaine applications
critiques de continuer à sexécuter et donc d'éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la comman de
tune2fs) n'est pas visible comme étant de l'espace libre quand
tu exécute la commande df.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 19:57, jerome
moliere a écrit :<br>
<div dir="ltr">Bonjour a tous les poilus,
<div>le probleme que j'ai n'est pas sous Debian mais je
pense qu'il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J'ai un /home tres gros sur mon SSD de 512Go (382Go)
en ext4 </div>
<div>du -h et df -h si je les utilise ne me livrent pas
une sortie coherente</div>
<div><br>
</div>
<div>
<div> ~> df -h /home/</div>
<div>Filesystem Size Used Avail Use% Mounted on</div>
<div>
/dev/sda9 381G 106G 256G 30% /home</ div>
</div>
<div><br>
</div>
<div>le du -h me donne 106Go</div>
<div><br>
</div>
<div>mais ou sont passes les 19Go ?</div>
<div>un lsof |grep deleted me ramene peut etre 30 ou 40 Mo
de fichiers flagges deleted donc il en manque
encore...C'est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s'il perd de la place ainsi</div>
<div><br>
</div>
<div>Je ne sais pas trop ou regarder pour en savoir plus ?</d iv>
<div>Il y a t'il une autre methode pour calculer l'es pace
dispo ?</div>
<div>Meme les arrondis n'expliquent pas de perdre 5%
d'espace disque ainsi ...</div>
<div><br>
</div>
<div>J'hesitais a voir avec un dd monstrueux si je pouvai s
creer un fichier de 260Go!!!</div>
<div>Mais peut etre que cela depasse les limites du kernel
ou du FS ?</div>
<div>bref je suis largue </div>
<div>
<br>
</div>
<div>merci a vous</div>
<div>PS:</div>
<div>j'ai aussi regarde dans le /proc et les resultats
sont bien ceux ramenes par lsof donc cette piste ne mene
a rien</div>
<div><br clear="all">
<div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid >
</div>
</blockquote>
<br>
</div></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>< Belaid >
</div>
--001a11c22634bac2cd04e73b0efd--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAFuS2bbHWEYBR70xV557gsCqgtz16G23TG1HNVF9O6iuh++
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Mais j'ai un / de 15 Go a cote ???
J.MOLIERE - Mentor/J
Le 25 septembre 2013 22:25, Belaïd
--001a113368760a546104e73b396d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class="h5"><br>
106 + 256 cela ne  fait pas 381 ....
<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<div><div><br>
<br>
C'est juste les arguments que tu utilises pour ces 2 commandes qu i
diffèrent dans les résultats.<br>
<br>
Comme tu l a fait avec lsof on voit que certains process gardent
des fichiers supprimés ouverts, ce qui n'est pas visible par "du"<br>
<br>
De plus ces commandes calculent de différentes manières : < br>
<br>
df prends la plupart des ses infos depuis le superblock du
filesystem<br>
df inclu les fichiers ouverts<br>
<br>
du remonte l'info à un instant T c'est que tu vois maint enant<br>
du n'inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d'autres différences<br>
<br>
Ces 2 commandes sont très bonnes et "équivalentes" ; mais "du" est
plus significative dans l'instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense qu e
Belaïd n'a pas saisi ta question ;)<br>
<br>
<br>
Le 09/25/2013 09:00 PM, Belaïd a écrit :<br>
</div></div></div><div><div><div><div>
<blockquote type="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées un système de fichier sur un disque, un
pourcentage de l'espace de stockage est réservé à root (par
défaut = 5%). Cet espace dédié permet de ne pas re mplir
complétement les disques, de permettre a certaine applications
critiques de continuer à sâexécuter et donc d' ;éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la commande
tune2fs) n'est pas visible comme étant de l'espace lib re quand
tu exécute la commande df.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 19:57, jerome
moliere a écrit :<br>
<div dir="ltr">Bonjour a tous les poilus,
<div>le probleme que j'ai n'est pas sous Debian mais je
pense qu'il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J'ai un /home tres gros sur mon SSD de 512Go (382Go)
en ext4Â </div>
<div>du -h et df -h si je les utilise ne me livrent pas
une sortie coherente</div>
<div><br>
</div>
<div>
<div> ~> df -h /home/</div>
<div>Filesystem    Size  Used Avail U se% Mounted on</div>
<div>
/dev/sda9 Â Â Â 381G Â 106G Â 256G Â 30% /home</div>
</div>
<div><br>
</div>
<div>le du -h me donne 106Go</div>
<div><br>
</div>
<div>mais ou sont passes les 19Go ?</div>
<div>un lsof |grep deleted me ramene peut etre 30 ou 40 Mo
de fichiers flagges deleted donc il en manque
encore...C'est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s'il perd de la place ainsi</div>
<div><br>
</div>
<div>Je ne sais pas trop ou regarder pour en savoir plus ?</d iv>
<div>Il y a t'il une autre methode pour calculer l'es pace
dispo ?</div>
<div>Meme les arrondis n'expliquent pas de perdre 5%
d'espace disque ainsi ...</div>
<div><br>
</div>
<div>J'hesitais a voir avec un dd monstrueux si je pouvai s
creer un fichier de  260Go!!!</div>
<div>Mais peut etre que cela depasse les limites du kernel
ou du FS ?</div>
<div>bref je suis largue </div>
<div>
<br>
</div>
<div>merci a vous</div>
<div>PS:</div>
<div>j'ai aussi regarde dans le /proc et les resultats
sont bien ceux ramenes par lsof donc cette piste ne mene
a rien</div>
<div><br clear="all">
<div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid >
</div>
</blockquote>
<br>
</div></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#88888 8"><br><br clear="all"><br>-- <br>< Belaid >
</font></span></div>
</blockquote></div><br></div>
--001a113368760a546104e73b396d--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAEGYFEKX+PDAQZfM7¢
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
/ et /home sont deux points de montage différent. Tu as 15G sur / et 381G
sur /home c'est bien ça ?. Sur chaque montage que tu peux avoir, tu as 5%
qui ne sont pas visible avec la commande df (sauf utilisation d'une option
de df, mais malheureusement je ne m'en souvient plus) et qui sont dédié
pour root. Si tu regarde tes 15G, logiquement tu aura le même constat que
pour /home
Le 25 septembre 2013 22:37, jerome moliere écrit :
--
< Belaid >
--001a11c38122f726b104e73b6bc9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
J.MOLIERE - Mentor/J<br><br></div></div>
<div><br>
106 + 256 cela ne fait pas 381 ....
<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<div><div><br>
<br>
C'est juste les arguments que tu utilises pour ces 2 commandes qu i
diffèrent dans les résultats.<br>
<br>
Comme tu l a fait avec lsof on voit que certains process gardent
des fichiers supprimés ouverts, ce qui n'est pas visible par &q uot;du"<br>
<br>
De plus ces commandes calculent de différentes manières : <br>
<br>
df prends la plupart des ses infos depuis le superblock du
filesystem<br>
df inclu les fichiers ouverts<br>
<br>
du remonte l'info à un instant T c'est que tu vois maintena nt<br>
du n'inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d'autres différences<br>
<br>
Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est
plus significative dans l'instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense que
Belaïd n'a pas saisi ta question ;)<br>
<br>
<br>
Le 09/25/2013 09:00 PM, Belaïd a écrit :<br>
</div></div></div><div><div><div><div>
<blockquote type="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées un système de fichier sur un disque, un
pourcentage de l'espace de stockage est réservé à root (p ar
défaut = 5%). Cet espace dédié permet de ne pas remplir
complétement les disques, de permettre a certaine applications
critiques de continuer à sexécuter et donc d'éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la comman de
tune2fs) n'est pas visible comme étant de l'espace libre quand
tu exécute la commande df.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 19:57, jerome
moliere a écrit :<br>
<div dir="ltr">Bonjour a tous les poilus,
<div>le probleme que j'ai n'est pas sous Debian mais je
pense qu'il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J'ai un /home tres gros sur mon SSD de 512Go (382Go)
en ext4 </div>
<div>du -h et df -h si je les utilise ne me livrent pas
une sortie coherente</div>
<div><br>
</div>
<div>
<div> ~> df -h /home/</div>
<div>Filesystem Size Used Avail Use% Mounted on</div>
<div>
/dev/sda9 381G 106G 256G 30% /home</ div>
</div>
<div><br>
</div>
<div>le du -h me donne 106Go</div>
<div><br>
</div>
<div>mais ou sont passes les 19Go ?</div>
<div>un lsof |grep deleted me ramene peut etre 30 ou 40 Mo
de fichiers flagges deleted donc il en manque
encore...C'est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s'il perd de la place ainsi</div>
<div><br>
</div>
<div>Je ne sais pas trop ou regarder pour en savoir plus ?</d iv>
<div>Il y a t'il une autre methode pour calculer l'es pace
dispo ?</div>
<div>Meme les arrondis n'expliquent pas de perdre 5%
d'espace disque ainsi ...</div>
<div><br>
</div>
<div>J'hesitais a voir avec un dd monstrueux si je pouvai s
creer un fichier de 260Go!!!</div>
<div>Mais peut etre que cela depasse les limites du kernel
ou du FS ?</div>
<div>bref je suis largue </div>
<div>
<br>
</div>
<div>merci a vous</div>
<div>PS:</div>
<div>j'ai aussi regarde dans le /proc et les resultats
sont bien ceux ramenes par lsof donc cette piste ne mene
a rien</div>
<div><br clear="all">
<div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid >
</div>
</blockquote>
<br>
</div></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div></div></div><span><font color="#888888"><br><br clear ="all"><br>-- <br>< Belaid >
</font></span></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>< Belaid >
</div>
--001a11c38122f726b104e73b6bc9--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAFuS2bYm94xgW=aohu+
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
man tune2fs, regarde l'option -m
Le 25 septembre 2013 23:05, Johnny B
--
< Belaid >
--089e016347fa5023a804e73bb353
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div bgcolor="#FFFFFF" text="#000000">
<div>Tu cherches a obtenir une info sur ton
FS a un instant T donc déjà il est plus "adapté" d 9;utiliser "du"<br>
<br>
Ensuite je cherche le truc des 5% mais jamais entendu parler, je
suis en xfs perso<br>
<br>
<br>
Le 09/25/2013 10:51 PM, Belaïd a écrit :<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">/ et /home sont deux points de montage différent.
Tu as 15G sur / et 381G sur /home c'est bien ça ?. Sur chaque
montage que tu peux avoir, tu as 5% qui ne sont pas visible avec
la commande df (sauf utilisation d'une option de df, mais
malheureusement je ne m'en souvient plus) et qui sont dédié pour
root. Si tu regarde tes 15G, logiquement tu aura le même constat
que pour /home<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 22:37, jerome
moliere a écrit :<br>
<div dir="ltr">Mais j'ai un / de 15 Go a cote ???</div>
<div class="gmail_extra"><br clear="all">
<div>
<div dir="ltr">
J.MOLIERE - Mentor/J<br>
<br>
</div>
</div>
<br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 22:25,
Belaïd a écrit :
<div>
<div><br>
<div dir="ltr">
<div>5% de tes 381 ~ 19 volés => les 5%
réservé a root selon ma vision.<br>
</div>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013
22:19, jerome moliere a écrit :
<div>
<div><br>
<div dir="ltr">Merci a Johnny et Belaid
<div>mais si tu regardes la sortie de
la commande df tu vois bien que :</div>
<div>
106 + 256 cela ne fait pas 381 ....< /div>
<div>et les fichiers reserved
representent peanuts ..</div>
<div>d'ou ma question ou sont mes Go
voles -)</div>
</div>
<div class="gmail_extra"><br clear="all ">
<div>
<br>
</div>
</div>
<br>
<br>
<div class="gmail_quote">
<div>Le 25 septembre 2013 21:47,
Johnny B a écrit :<br>
</div>
<div bgcolor="#FFFFFF" text="#000 000">
<div>Salut,
<div>
<div><br>
<br>
C'est juste les arguments
que tu utilises pour ces 2
commandes qui diffèrent
dans les résultats.<br>
<br>
Comme tu l a fait avec
lsof on voit que certains
process gardent des
fichiers supprimés
ouverts, ce qui n'est pas
visible par "du"<br >
<br>
De plus ces commandes
calculent de différentes
manières : <br>
<br>
df prends la plupart des
ses infos depuis le
superblock du filesystem<br>
df inclu les fichiers
ouverts<br>
<br>
du remonte l'info à un
instant T c'est que tu
vois maintenant<br>
du n'inclut pas les
fichiers ouverts et ne se
base pas sur la taille des
block<br>
<br>
et surement bien d'autres
différences<br>
<br>
Ces 2 commandes sont très
bonnes et "équivalente s"
mais "du" est plus
significative dans
l'instant T<br>
<br>
ps : rien à voir avec le
/root cité ci dessous, je
pense que Belaïd n'a pa s
saisi ta question ;)<br>
<br>
<br>
Le 09/25/2013 09:00 PM,
Belaïd a écrit :<br>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées un
système de fichier
sur un disque, un
pourcentage de
l'espace de stockag e
est réservé à roo t
(par défaut = 5%).
Cet espace dédié
permet de ne pas
remplir complétement
les disques, de
permettre a certaine
applications
critiques de
continuer à
sexécuter et donc
d'éviter de bloqu er
le systéme. Cet
espace de 5% dédié
(modifiable avec la
commande tune2fs)
n'est pas visible
comme étant de
l'espace libre quan d
tu exécute la
commande df.<br>
</div>
<div class="gmail_extra "><br>
<br>
<div class="gmail_quo te">Le
25 septembre 2013
19:57, jerome
moliere a écrit :<br>
<div dir="ltr">Bo njour
a tous les
poilus,
<div>le
probleme que
j'ai n'es t pas
sous Debian
mais je pense
qu'il pourrai t
se poser.</div>
<div>Il est
sous Manjaro
(archlinux)</div>
<div>J'ai un
/home tres
gros sur mon
SSD de 512Go
(382Go) en
ext4 </div>
<div>du -h et
df -h si je
les utilise ne
me livrent pas
une sortie
coherente</div>
<div><br>
</div>
<div>
<div> njaro-laptop
~> df -h
/home/</div>
<div>Filesystem
Size
Used Avail
Use% Mounted
on</div>
<div>
/dev/sda9
381G 106G
256G 30%
/home</div>
</div>
<div><br>
</div>
<div>le du -h
me donne 106Go</d iv>
<div><br>
</div>
<div>mais ou
sont passes
les 19Go ?</div>
<div>un lsof
|grep deleted
me ramene peut
etre 30 ou 40
Mo de fichiers
flagges
deleted donc
il en manque
encore...C'es t
pas grave mais
du coup je me
pose beaucoup
de questions
car mon /
pourrait vite
saturer s'il
perd de la
place ainsi</div>
<div><br>
</div>
<div>Je ne
sais pas trop
ou regarder
pour en savoir
plus ?</div>
<div>Il y a
t'il une autr e
methode pour
calculer
l'espace disp o
?</div>
<div>Meme les
arrondis
n'expliquent
pas de perdre
5% d'espace
disque ainsi
...</div>
<div><br>
</div>
<div>J'hesita is
a voir avec un
dd monstrueux
si je pouvais
creer un
fichier de
260Go!!!</div>
<div>Mais peut
etre que cela
depasse les
limites du
kernel ou du
FS ?</div>
<div>bref je
suis largue </d iv>
<div> <br>
</div>
<div>merci a
vous</div>
<div>PS:</div>
<div>j'ai
aussi regarde
dans le /proc
et les
resultats sont
bien ceux
ramenes par
lsof donc
cette piste ne
mene a rien</div>
<div><br clear= "all">
<div>
<div dir="ltr"> J.MOLIERE
- Mentor/J<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid > </div>
</blockquote>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
<span><font color="#888888"><br>
<br clear="all">
<br>
-- <br>
< Belaid >
</font></span></div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid >
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>< Belaid >
</div>
--089e016347fa5023a804e73bb353--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Lol bon tu sais se qui te reste a faire :-) .... laisse tombé la pinte et
met toi au jack ;-)
Le 25 sept. 2013 23:35, "Johnny B"
--001a11c381225df9d104e73cb598
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div bgcolor="#FFFFFF" text="#000000">
<div>J'en profite pour dériver en HS, mais
ext4 (qui a encore de beaux jours) ne verra jamais ext5 sachant
que le standard va passer au btrfs dans l'avenir alors c'est le
moment de changer, de récupérer ses 5% et de passer à XFS qui e st
largement aussi powerfull ;)<br>
<br>
voila pour le coup de provoc =)<br>
<br>
Le 09/25/2013 11:26 PM, Johnny B a écrit :<br>
</div>
<blockquote type="cite">
<div>Autant pour moi merci pour l'info sur
tune2fs. <br>
<br>
En revanche c'est lié aux partitions ext mais ce qui est biza rre
c'est que ext4 a un système de défrag online et de bloc
allocator<br>
<br>
<br>
Je ne constate pas le problème étant en xfs et tune2fs étant du
"only ext3/ext4"<br>
<br>
Belle avancée ;)<br>
<br>
<br>
Le 09/25/2013 11:11 PM, Belaïd a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">man tune2fs, regarde l'option -m<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 23:05, Johnny B
a écrit :<br>
<div bgcolor="#FFFFFF" text="#000000">
<div>Tu cherches a obtenir une info sur ton FS a un
instant T donc déjà il est plus "adapté" d'utiliser
"du"<br>
<br>
Ensuite je cherche le truc des 5% mais jamais entendu
parler, je suis en xfs perso<br>
<br>
<br>
Le 09/25/2013 10:51 PM, Belaïd a écrit :<br>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">/ et /home sont deux points de
montage différent. Tu as 15G sur / et 381G sur
/home c'est bien ça ?. Sur chaque montage que tu
peux avoir, tu as 5% qui ne sont pas visible
avec la commande df (sauf utilisation d'une
option de df, mais malheureusement je ne m'en
souvient plus) et qui sont dédié pour root. Si
tu regarde tes 15G, logiquement tu aura le même
constat que pour /home<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013
22:37, jerome moliere a écrit :<br>
<div dir="ltr">Mais j'ai un / de 15 Go a
cote ???</div>
<div class="gmail_extra"><br clear="all">
<div>
<br>
</div>
</div>
<br>
<br>
<div class="gmail_quote">Le 25 septembre
2013 22:25, Belaïd a écrit :
<div>
<div><br>
<div dir="ltr">
<div>5% de tes 381 ~ 19 volés
=> les 5% réservé a root
selon ma vision.<br>
</div>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25
septembre 2013 22:19, jerome
moliere a écrit :
<div>
<div><br>
<div dir="ltr">Merci a
Johnny et Belaid
<div>mais si tu
regardes la sortie
de la commande df tu
vois bien que :</div>
<div> 106 + 256 cela
ne fait pas 381
....</div>
<div>et les fichiers
reserved
representent peanuts
..</div>
<div>d'ou ma question
ou sont mes Go voles
-)</div>
</div>
<div class="gmail_extra"> <br clear="all">
<div>
<div dir="ltr">J.MOLI ERE
- Mentor/J<br>
<br>
</div>
</div>
<br>
<br>
<div class="gmail_quote ">
<div>Le 25 septembre
2013 21:47, Johnny
B a écrit :<br>
</div>
<div bgcolor="#FFFF FF" text="#000000">
<div>Salut,
<div>
<div><br>
<br>
C'est juste
les arguments
que tu
utilises pour
ces 2
commandes qui
diffèrent dans
les résultats.< br>
<br>
Comme tu l a
fait avec lsof
on voit que
certains
process
gardent des
fichiers
supprimés
ouverts, ce
qui n'est pas
visible par
"du"<br >
<br>
De plus ces
commandes
calculent de
différentes
manières : <br>
<br>
df prends la
plupart des
ses infos
depuis le
superblock du
filesystem<br>
df inclu les
fichiers
ouverts<br>
<br>
du remonte
l'info à un
instant T
c'est que tu
vois
maintenant<br>
du n'inclut
pas les
fichiers
ouverts et ne
se base pas
sur la taille
des block<br>
<br>
et surement
bien d'autres
différences<br>
<br>
Ces 2
commandes sont
très bonnes et
"équivalen tes"
mais "du&quo t; est
plus
significative
dans l'instan t
T<br>
<br>
ps : rien à
voir avec le
/root cité ci
dessous, je
pense que
Belaïd n'a pas
saisi ta
question ;)<br >
<br>
<br>
Le 09/25/2013
09:00 PM,
Belaïd a
écrit :<br>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<blockquote type ="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu crées
un système de
fichier sur un
disque, un
pourcentage de
l'espace de
stockage est
réservé à r oot
(par défaut =
5%). Cet
espace dédié
permet de ne
pas remplir
complétement
les disques,
de permettre a
certaine
applications
critiques de
continuer à
sexécuter et
donc d'évit er
de bloquer le
systéme. Cet
espace de 5%
dédié
(modifiable
avec la
commande
tune2fs) n'es t
pas visible
comme étant de
l'espace libr e
quand tu
exécute la
commande df.<br>
</div>
<div class="gma il_extra"><br>
<br>
<div class="gma il_quote">Le
25 septembre
2013 19:57,
jerome moliere
a écrit :<br>
<div dir="ltr"> Bonjour
a tous les
poilus,
<div>le
probleme que
j'ai n'es t pas
sous Debian
mais je pense
qu'il pourrai t
se poser.</div>
<div>Il est
sous Manjaro
(archlinux)</div>
<div>J'ai un
/home tres
gros sur mon
SSD de 512Go
(382Go) en
ext4 </div>
<div>du -h et
df -h si je
les utilise ne
me livrent pas
une sortie
coherente</div>
<div><br>
</div>
<div>
<div> njaro-laptop
~> df -h
/home/</div>
<div>Filesystem
Size
Used Avail
Use% Mounted
on</div>
<div>
/dev/sda9
381G 106G
256G 30%
/home</div>
</div>
<div><br>
</div>
<div>le du -h
me donne 106Go</d iv>
<div><br>
</div>
<div>mais ou
sont passes
les 19Go ?</div>
<div>un lsof
|grep deleted
me ramene peut
etre 30 ou 40
Mo de fichiers
flagges
deleted donc
il en manque
encore...C'es t
pas grave mais
du coup je me
pose beaucoup
de questions
car mon /
pourrait vite
saturer s'il
perd de la
place ainsi</div>
<div><br>
</div>
<div>Je ne
sais pas trop
ou regarder
pour en savoir
plus ?</div>
<div>Il y a
t'il une autr e
methode pour
calculer
l'espace disp o
?</div>
<div>Meme les
arrondis
n'expliquent
pas de perdre
5% d'espace
disque ainsi
...</div>
<div><br>
</div>
<div>J'hesita is
a voir avec un
dd monstrueux
si je pouvais
creer un
fichier de
260Go!!!</div>
<div>Mais peut
etre que cela
depasse les
limites du
kernel ou du
FS ?</div>
<div>bref je
suis largue </d iv>
<div> <br>
</div>
<div>merci a
vous</div>
<div>PS:</div>
<div>j'ai
aussi regarde
dans le /proc
et les
resultats sont
bien ceux
ramenes par
lsof donc
cette piste ne
mene a rien</div>
<div><br clear= "all">
<div>
<div dir="ltr"> J.MOLIERE
- Mentor/J<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all" >
<br>
-- <br>
< Belaid
> </div>
</blockquote>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
<span><font color="#888888"><br>
<br clear="all">
<br>
-- <br>
< Belaid > </font></span> </div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid > </div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid > </div>
</blockquote>
<br>
</blockquote>
<br>
</div>
</blockquote></div>
--001a11c381225df9d104e73cb598--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
merci bien Belaid, la man page conforte ta reponse.Je ne savais pas que le
systeme se reservait de la place en cas de plantage....Mais bon je ne vois
pas ce qu'il irait ecrire dans mon /home .
je vais tenter un coup de tune2fs pour voir ..
Merci encore a toi
J.MOLIERE - Mentor/J
Le 26 septembre 2013 00:23, Belaïd
--089e0141a16e57fbb204e74b5e15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div bgcolor="#FFFFFF" text="#000000">
<div>J'en profite pour dériver en HS, mais
ext4 (qui a encore de beaux jours) ne verra jamais ext5 sachant
que le standard va passer au btrfs dans l'avenir alors c'est le
moment de changer, de récupérer ses 5% et de passer à XFS qui est
largement aussi powerfull ;)<br>
<br>
voila pour le coup de provoc =)<br>
<br>
Le 09/25/2013 11:26 PM, Johnny B a écrit :<br>
</div>
<blockquote type="cite">
<div>Autant pour moi merci pour l'info sur
tune2fs. <br>
<br>
En revanche c'est lié aux partitions ext mais ce qui est b izarre
c'est que ext4 a un système de défrag online et de bl oc
allocator<br>
<br>
<br>
Je ne constate pas le problème étant en xfs et tune2fs étant du
"only ext3/ext4"<br>
<br>
Belle avancée ;)<br>
<br>
<br>
Le 09/25/2013 11:11 PM, Belaïd a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">man tune2fs, regarde l'option -m<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013 23:05, Johnny B
a écrit :<br>
<div bgcolor="#FFFFFF" text="#000000">
<div>Tu cherches a obtenir une info sur ton FS a un
instant T donc déjà il est plus "adaptà ©" d'utiliser
"du"<br>
<br>
Ensuite je cherche le truc des 5% mais jamais entendu
parler, je suis en xfs perso<br>
<br>
<br>
Le 09/25/2013 10:51 PM, Belaïd a écrit :<b r>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">/ et /home sont deux points de
montage différent. Tu as 15G sur / et 381G sur
/home c'est bien ça ?. Sur chaque montage que tu
peux avoir, tu as 5% qui ne sont pas visible
avec la commande df (sauf utilisation d'une
option de df, mais malheureusement je ne m'en
souvient plus) et qui sont dédié pour roo t. Si
tu regarde tes 15G, logiquement tu aura le mêm e
constat que pour /home<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25 septembre 2013
22:37, jerome moliere a écrit :<br>
<div dir="ltr">Mais j'ai un / de 15 Go a
cote ???</div>
<div class="gmail_extra"><br clear="all">
<div>
<br>
</div>
</div>
<br>
<br>
<div class="gmail_quote">Le 25 septembre
2013 22:25, Belaïd a écrit :
<div>
<div><br>
<div dir="ltr">
<div>5% de tes 381 ~ 19 volés
=> les 5% réservé a root
selon ma vision.<br>
</div>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 25
septembre 2013 22:19, jerome
moliere a écrit :
<div>
<div><br>
<div dir="ltr">Merci a
Johnny et Belaid
<div>mais si tu
regardes la sortie
de la commande df tu
vois bien que :</div>
<div> 106 + 256 cela
ne  fait pas 381
....</div>
<div>et les fichiers
reserved
representent peanuts
..</div>
<div>d'ou ma question
ou sont mes Go voles
-)</div>
</div>
<div class="gmail_extra"> <br clear="all">
<div>
<div dir="ltr">J.MOLI ERE
- Mentor/J<br>
<br>
</div>
</div>
<br>
<br>
<div class="gmail_quote ">
<div>Le 25 septembre
2013 21:47, Johnny
B a écrit :<br>
</div>
<div bgcolor="#FFFF FF" text="#000000">
<div>Salut,
<div>
<div><br>
<br>
C'est juste
les arguments
que tu
utilises pour
ces 2
commandes qui
diffèrent da ns
les résultat s.<br>
<br>
Comme tu l a
fait avec lsof
on voit que
certains
process
gardent des
fichiers
supprimés
ouverts, ce
qui n'est pas
visible par
"du"<br >
<br>
De plus ces
commandes
calculent de
différentes
manières : < br>
<br>
df prends la
plupart des
ses infos
depuis le
superblock du
filesystem<br>
df inclu les
fichiers
ouverts<br>
<br>
du remonte
l'info à un
instant T
c'est que tu
vois
maintenant<br>
du n'inclut
pas les
fichiers
ouverts et ne
se base pas
sur la taille
des block<br>
<br>
et surement
bien d'autres
différences< br>
<br>
Ces 2
commandes sont
très bonnes et
"équiva lentes"
mais "du&quo t; est
plus
significative
dans l'instan t
T<br>
<br>
ps : rien Ã
voir avec le
/root cité c i
dessous, je
pense que
Belaïd n' ;a pas
saisi ta
question ;) <br>
<br>
<br>
Le 09/25/2013
09:00 PM,
Belaïd a
écrit : <br>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<blockquote type ="cite">
<div dir="ltr">
<div>Bonsoir,<br>
</div>
Quand tu cré es
un système d e
fichier sur un
disque, un
pourcentage de
l'espace de
stockage est
réservé à root
(par défaut =
5%). Cet
espace dédi é
permet de ne
pas remplir
complétement
les disques,
de permettre a
certaine
applications
critiques de
continuer Ã
sâexà ©cuter et
donc d'é viter
de bloquer le
systéme. Cet
espace de 5%
dédié
(modifiable
avec la
commande
tune2fs) n'es t
pas visible
comme étant de
l'espace libr e
quand tu
exécute la
commande df.<br>
</div>
<div class="gma il_extra"><br>
<br>
<div class="gma il_quote">Le
25 septembre
2013 19:57,
jerome moliere
a écrit :<br >
<div dir="ltr"> Bonjour
a tous les
poilus,
<div>le
probleme que
j'ai n'es t pas
sous Debian
mais je pense
qu'il pourrai t
se poser.</div>
<div>Il est
sous Manjaro
(archlinux)</div>
<div>J'ai un
/home tres
gros sur mon
SSD de 512Go
(382Go) en
ext4Â </div>
<div>du -h et
df -h si je
les utilise ne
me livrent pas
une sortie
coherente</div>
<div><br>
</div>
<div>
<div> njaro-laptop
~> df -h
/home/</div>
<div>Filesystem
   Size
 Used Avail
Use% Mounted
on</div>
<div>
/dev/sda9 Â Â
 381G  106G
 256G  30%
/home</div>
</div>
<div><br>
</div>
<div>le du -h
me donne 106Go</d iv>
<div><br>
</div>
<div>mais ou
sont passes
les 19Go ?</div>
<div>un lsof
|grep deleted
me ramene peut
etre 30 ou 40
Mo de fichiers
flagges
deleted donc
il en manque
encore...C'es t
pas grave mais
du coup je me
pose beaucoup
de questions
car mon /
pourrait vite
saturer s'il
perd de la
place ainsi</div>
<div><br>
</div>
<div>Je ne
sais pas trop
ou regarder
pour en savoir
plus ?</div>
<div>Il y a
t'il une autr e
methode pour
calculer
l'espace disp o
?</div>
<div>Meme les
arrondis
n'expliquent
pas de perdre
5% d'espace
disque ainsi
...</div>
<div><br>
</div>
<div>J'hesita is
a voir avec un
dd monstrueux
si je pouvais
creer un
fichier de
 260Go!!!</d iv>
<div>Mais peut
etre que cela
depasse les
limites du
kernel ou du
FS ?</div>
<div>bref je
suis largue </div>
<div> <br>
</div>
<div>merci a
vous</div>
<div>PS:</div>
<div>j'ai
aussi regarde
dans le /proc
et les
resultats sont
bien ceux
ramenes par
lsof donc
cette piste ne
mene a rien</div>
<div><br clear= "all">
<div>
<div dir="ltr"> J.MOLIERE
- Mentor/J<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all" >
<br>
-- <br>
< Belaid
> </div>
</blockquote>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
<span><font color="#888888"><br>
<br clear="all">
<br>
-- <br>
< Belaid > </font></span> </div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid > </div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
< Belaid > </div>
</blockquote>
<br>
</blockquote>
<br>
</div>
</blockquote></div></div></div>
</blockquote></div><br></div>
--089e0141a16e57fbb204e74b5e15--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAEGYFEL3QhRNpbOA2scy_Za2mEzXA-ubq7VTog-9E2hVû