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&#39;ai n&=
#39;est pas sous Debian mais je pense qu&#39;il pourrait se poser.</div><di=
v>Il est sous Manjaro (archlinux)</div><div>J&#39;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 ~&gt; 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&#39;est pas grave mais du coup je me pose beaucoup de questions car mon /=
pourrait vite saturer s&#39;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&#39;il une autre methode pour calculer l&#39;espace dispo=
?</div><div>Meme les arrondis n&#39;expliquent pas de perdre 5% d&#39;espa=
ce disque ainsi </div>

<div><br></div><div>J&#39;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&#39;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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Belaïd
Le #25684642
--bcaec53f3959a472f804e739dc6e
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 à s’exé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 :

Bonjour a tous les poilus,
le probleme que j'ai n'est pas sous Debian mais je pense qu'il pourrait s e
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

~> 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 encore...C'est pas grave mais du coup je me pos e
beaucoup de questions car mon / pourrait vite saturer s'il perd de la pla ce
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






--
< Belaid >

--bcaec53f3959a472f804e739dc6e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>Il est sous Manjaro (archlinux)</div><div>J&#39;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> ~&gt; 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&#39;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>&lt; Belaid &gt;
</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+
Belaïd
Le #25684892
--089e013d1eaac15eea04e73a9c1f
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
Salut,

C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesystem
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille des
block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est plus
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Belaïd n'a
pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

Bonsoir,
Quand tu crées un système de fichier sur un disque, un pourcentage d e
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 certa ine
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 comm ande
tune2fs) n'est pas visible comme étant de l'espace libre quand tu exé cute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere écrit :

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

~> 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 flagge s
deleted donc il en manque encore...C'est pas grave mais du coup je me po se
beaucoup de questions car mon / pourrait vite saturer s'il perd de la pl ace
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






--
< Belaid >







--
< Belaid >

--089e013d1eaac15eea04e73a9c1f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<br>
<br>
C&#39;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&#39;est pas visible par &q uot;du&quot;<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&#39;info à un instant T c&#39;est que tu vois maintena nt<br>
du n&#39;inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d&#39;autres différences<br>
<br>
Ces 2 commandes sont très bonnes et &quot;équivalentes&quot; mais &quot;du&quot; est
plus significative dans l&#39;instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense que
Belaïd n&#39;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&#39;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 à s’exécuter et donc d&#39;éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la comman de
tune2fs) n&#39;est pas visible comme étant de l&#39;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&#39;ai n&#39;est pas sous Debian mais je
pense qu&#39;il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J&#39;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> ~&gt; 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&#39;est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s&#39;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&#39;il une autre methode pour calculer l&#39;es pace
dispo ?</div>
<div>Meme les arrondis n&#39;expliquent pas de perdre 5%
d&#39;espace disque ainsi ...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid &gt;
</div>
</blockquote>
<br>
</div></div></div>

</blockquote></div><br><br clear="all"><br>-- <br>&lt; Belaid &gt;
</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ö=
Belaïd
Le #25684962
--089e010d86880e92ec04e73ab4d2
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"
Relis avec une grosse pinte ca passera mieux =)

Le 09/25/2013 09:53 PM, Belaïd a écrit :

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
Salut,

C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesystem
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille des
block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est plu s
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Belaï d n'a
pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

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 espace dédié
permet de ne pas remplir complétement les disques, de permettre a cert aine
applications critiques de continuer à s’exécuter et donc d'évite r de
bloquer le systéme. Cet espace de 5% dédié (modifiable avec la com mande
tune2fs) n'est pas visible comme étant de l'espace libre quand tu ex écute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere écrit :

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

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

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 ramene s
par lsof donc cette piste ne mene a rien

J.MOLIERE - Mentor/J






--
< Belaid >







--
< Belaid >






--089e010d86880e92ec04e73ab4d2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<p dir="ltr">A ouai c&#39;est vrai ! j&#39;é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&#39;avoue que j&#39;ai relu encore la
question =&gt; 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&#39;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&#39;est pas
visible par &quot;du&quot;<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&#39;info à un instant T c&#39;est que tu voi s
maintenant<br>
du n&#39;inclut pas les fichiers ouverts et ne se base pas
sur la taille des block<br>
<br>
et surement bien d&#39;autres différences<br>
<br>
Ces 2 commandes sont très bonnes et &quot;équivalentes& quot; mais
&quot;du&quot; est plus significative dans l&#39;instant T< br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pens e
que Belaïd n&#39;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&#39;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 à s’exécuter et donc d&#39;éviter d e bloquer
le systéme. Cet espace de 5% dédié (modifiable
avec la commande tune2fs) n&#39;est pas visible comme
étant de l&#39;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&#39;ai n&#39;est pas sou s
Debian mais je pense qu&#39;il pourrait se
poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J&#39;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> ~&gt; 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&#39;est
pas grave mais du coup je me pose beaucoup
de questions car mon / pourrait vite
saturer s&#39;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&#39;il une autre methode pour
calculer l&#39;espace dispo ?</div>
<div>Meme les arrondis n&#39;expliquent pas de
perdre 5% d&#39;espace disque ainsi ...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid &gt; </div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
&lt; Belaid &gt;
</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+
jerome moliere
Le #25685022
--089e013d14ca95622804e73af8b0
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
Salut,

C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesystem
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille des
block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" es t plus
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Be laïd n'a
pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

Bonsoir,
Quand tu crées un système de fichier sur un disque, un pourcen tage 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 ce rtaine
applications critiques de continuer à s’exécuter et don c d'éviter de
bloquer le systéme. Cet espace de 5% dédié (modifiable ave c la commande
tune2fs) n'est pas visible comme étant de l'espace libre quand tu ex écute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere écrit :

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

~> 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 flagge s
deleted donc il en manque encore...C'est pas grave mais du coup je me po se
beaucoup de questions car mon / pourrait vite saturer s'il perd de la pl ace
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






--
< Belaid >






--089e013d14ca95622804e73af8b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable







<div bgcolor="#FFFFFF" text="#000000">
<div>Salut,<br>
<br>
C&#39;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&#39;est pas visible par &quot;du&quot;<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&#39;info à un instant T c&#39;est que tu vois maint enant<br>
du n&#39;inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d&#39;autres différences<br>
<br>
Ces 2 commandes sont très bonnes et &quot;équivalentes&quot ; mais &quot;du&quot; est
plus significative dans l&#39;instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense qu e
Belaïd n&#39;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&#39;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&#39 ;éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la commande
tune2fs) n&#39;est pas visible comme étant de l&#39;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&#39;ai n&#39;est pas sous Debian mais je
pense qu&#39;il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J&#39;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> ~&gt; 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&#39;est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s&#39;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&#39;il une autre methode pour calculer l&#39;es pace
dispo ?</div>
<div>Meme les arrondis n&#39;expliquent pas de perdre 5%
d&#39;espace disque ainsi ...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid &gt;
</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/
Belaïd
Le #25685082
--001a11c22634bac2cd04e73b0efd
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 :

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
Salut,


C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesystem
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille des
block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est plu s
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Belaï d n'a
pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

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 espace dédié
permet de ne pas remplir complétement les disques, de permettre a cert aine
applications critiques de continuer à s’exécuter et donc d'évite r de
bloquer le systéme. Cet espace de 5% dédié (modifiable avec la com mande
tune2fs) n'est pas visible comme étant de l'espace libre quand tu ex écute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere écrit :

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

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

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 ramene s
par lsof donc cette piste ne mene a rien

J.MOLIERE - Mentor/J






--
< Belaid >










--
< 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&#39;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&#39;est pas visible par &q uot;du&quot;<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&#39;info à un instant T c&#39;est que tu vois maintena nt<br>
du n&#39;inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d&#39;autres différences<br>
<br>
Ces 2 commandes sont très bonnes et &quot;équivalentes&quot; mais &quot;du&quot; est
plus significative dans l&#39;instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense que
Belaïd n&#39;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&#39;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 à s’exécuter et donc d&#39;éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la comman de
tune2fs) n&#39;est pas visible comme étant de l&#39;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&#39;ai n&#39;est pas sous Debian mais je
pense qu&#39;il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J&#39;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> ~&gt; 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&#39;est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s&#39;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&#39;il une autre methode pour calculer l&#39;es pace
dispo ?</div>
<div>Meme les arrondis n&#39;expliquent pas de perdre 5%
d&#39;espace disque ainsi ...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid &gt;
</div>
</blockquote>
<br>
</div></div></div></div></div>

</blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>&lt; Belaid &gt;
</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++
jerome moliere
Le #25685072
--001a113368760a546104e73b396d
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
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 :

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
Salut,


C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesystem
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille de s
block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est plus
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Belaïd n'a
pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

Bonsoir,
Quand tu crées un système de fichier sur un disque, un pourc entage 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 d onc d'éviter de
bloquer le systéme. Cet espace de 5% dédié (modifiable a vec la commande
tune2fs) n'est pas visible comme étant de l'espace libre quand tu exécute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere écrit :

Bonjour a tous les poilus,
le probleme que j'ai n'est pas sous Debian mais je pense qu'il pourrai t
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 coherent e

~> 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 encore...C'est pas grave mais du cou p je
me pose beaucoup de questions car mon / pourrait vite saturer s'il per d 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






--
< Belaid >










--
< Belaid >




--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&#39;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&#39;est pas visible par &quot;du&quot;<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&#39;info à un instant T c&#39;est que tu vois maint enant<br>
du n&#39;inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d&#39;autres différences<br>
<br>
Ces 2 commandes sont très bonnes et &quot;équivalentes&quot ; mais &quot;du&quot; est
plus significative dans l&#39;instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense qu e
Belaïd n&#39;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&#39;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&#39 ;éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la commande
tune2fs) n&#39;est pas visible comme étant de l&#39;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&#39;ai n&#39;est pas sous Debian mais je
pense qu&#39;il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J&#39;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> ~&gt; 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&#39;est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s&#39;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&#39;il une autre methode pour calculer l&#39;es pace
dispo ?</div>
<div>Meme les arrondis n&#39;expliquent pas de perdre 5%
d&#39;espace disque ainsi ...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid &gt;
</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>&lt; Belaid &gt;
</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¢
Belaïd
Le #25685092
--001a11c38122f726b104e73b6bc9
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 :

Mais j'ai un / de 15 Go a cote ???

J.MOLIERE - Mentor/J



Le 25 septembre 2013 22:25, Belaïd
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 :

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
Salut,


C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesystem
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille
des block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est p lus
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Bela ïd n'a
pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

Bonsoir,
Quand tu crées un système de fichier sur un disque, un pourcentag e de
l'espace de stockage est réservé à root (par défaut = 5%). C et espace dédié
permet de ne pas remplir complétement les disques, de permettre a ce rtaine
applications critiques de continuer à s’exécuter et donc d'évi ter de
bloquer le systéme. Cet espace de 5% dédié (modifiable avec la c ommande
tune2fs) n'est pas visible comme étant de l'espace libre quand tu ex écute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere
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 coheren te

~> 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 encore...C'est pas grave mais du co up je
me pose beaucoup de questions car mon / pourrait vite saturer s'il pe rd 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






--
< Belaid >










--
< Belaid >









--
< 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&#39;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&#39;est pas visible par &q uot;du&quot;<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&#39;info à un instant T c&#39;est que tu vois maintena nt<br>
du n&#39;inclut pas les fichiers ouverts et ne se base pas sur la
taille des block<br>
<br>
et surement bien d&#39;autres différences<br>
<br>
Ces 2 commandes sont très bonnes et &quot;équivalentes&quot; mais &quot;du&quot; est
plus significative dans l&#39;instant T<br>
<br>
ps : rien à voir avec le /root cité ci dessous, je pense que
Belaïd n&#39;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&#39;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 à s’exécuter et donc d&#39;éviter de bloquer
le systéme. Cet espace de 5% dédié (modifiable avec la comman de
tune2fs) n&#39;est pas visible comme étant de l&#39;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&#39;ai n&#39;est pas sous Debian mais je
pense qu&#39;il pourrait se poser.</div>
<div>Il est sous Manjaro (archlinux)</div>
<div>J&#39;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> ~&gt; 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&#39;est pas grave mais du coup je me pose
beaucoup de questions car mon / pourrait vite saturer
s&#39;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&#39;il une autre methode pour calculer l&#39;es pace
dispo ?</div>
<div>Meme les arrondis n&#39;expliquent pas de perdre 5%
d&#39;espace disque ainsi ...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid &gt;
</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>&lt; Belaid &gt;
</font></span></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>&lt; Belaid &gt;
</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+
Belaïd
Le #25685202
--089e016347fa5023a804e73bb353
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
Tu cherches a obtenir une info sur ton FS a un instant T donc déjà i l
est plus "adapté" d'utiliser "du"

Ensuite je cherche le truc des 5% mais jamais entendu parler, je suis en
xfs perso


Le 09/25/2013 10:51 PM, Belaïd a écrit :

/ et /home sont deux points de montage différent. Tu as 15G sur / et 38 1G
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 optio n
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 q ue
pour /home


Le 25 septembre 2013 22:37, jerome moliere écrit :

Mais j'ai un / de 15 Go a cote ???

J.MOLIERE - Mentor/J



Le 25 septembre 2013 22:25, Belaïd
5% de tes 381 ~ 19 volés => les 5% réservé a root selon ma visi on.



Le 25 septembre 2013 22:19, jerome moliere écrit :

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 :

Salut,


C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesystem
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille
des block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est plus
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Bela ïd
n'a pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

Bonsoir,
Quand tu crées un système de fichier sur un disque, un pourcenta ge 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 c ertaine
applications critiques de continuer à s’exécuter et donc d'év iter 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 libre quand tu e xécute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere
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

~> 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 encore...C'est pas grave mais du c oup je
me pose beaucoup de questions car mon / pourrait vite saturer s'il p erd 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 ains i
...

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






--
< Belaid >










--
< Belaid >









--
< Belaid >







--
< 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 &quot;adapté&quot; d&#3 9;utiliser &quot;du&quot;<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&#39;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&#39;une option de df, mais
malheureusement je ne m&#39;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&#39;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 =&gt; 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&#39;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&#39;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&#39;est pas
visible par &quot;du&quot;<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&#39;info à un
instant T c&#39;est que tu
vois maintenant<br>
du n&#39;inclut pas les
fichiers ouverts et ne se
base pas sur la taille des
block<br>
<br>
et surement bien d&#39;autres
différences<br>
<br>
Ces 2 commandes sont très
bonnes et &quot;équivalente s&quot;
mais &quot;du&quot; est plus
significative dans
l&#39;instant T<br>
<br>
ps : rien à voir avec le
/root cité ci dessous, je
pense que Belaïd n&#39;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&#39;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 à
s’exécuter et donc
d&#39;éviter de bloqu er
le systéme. Cet
espace de 5% dédié
(modifiable avec la
commande tune2fs)
n&#39;est pas visible
comme étant de
l&#39;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&#39;ai n&#39;es t pas
sous Debian
mais je pense
qu&#39;il pourrai t
se poser.</div>
<div>Il est
sous Manjaro
(archlinux)</div>
<div>J&#39;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
~&gt; 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&#39;es t
pas grave mais
du coup je me
pose beaucoup
de questions
car mon /
pourrait vite
saturer s&#39;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&#39;il une autr e
methode pour
calculer
l&#39;espace disp o
?</div>
<div>Meme les
arrondis
n&#39;expliquent
pas de perdre
5% d&#39;espace
disque ainsi
...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid &gt; </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>
&lt; Belaid &gt;
</font></span></div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
&lt; Belaid &gt;
</div>
</blockquote>
<br>
</div></div></div>

</blockquote></div><br><br clear="all"><br>-- <br>&lt; Belaid &gt;
</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/
Belaïd
Le #25685322
--001a11c381225df9d104e73cb598
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"
J'en profite pour dériver en HS, mais ext4 (qui a encore de beaux jour s)
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 ;)

voila pour le coup de provoc =)

Le 09/25/2013 11:26 PM, Johnny B a écrit :

Autant pour moi merci pour l'info sur tune2fs.

En revanche c'est lié aux partitions ext mais ce qui est bizarre c'est que
ext4 a un système de défrag online et de bloc allocator

https://wiki.archlinux.org/index.php/Ext4

Je ne constate pas le problème étant en xfs et tune2fs étant du "on ly
ext3/ext4"

Belle avancée ;)


Le 09/25/2013 11:11 PM, Belaïd a écrit :

man tune2fs, regarde l'option -m


Le 25 septembre 2013 23:05, Johnny B
Tu cherches a obtenir une info sur ton FS a un instant T donc déjà il
est plus "adapté" d'utiliser "du"

Ensuite je cherche le truc des 5% mais jamais entendu parler, je suis en
xfs perso


Le 09/25/2013 10:51 PM, Belaïd a écrit :

/ et /home sont deux points de montage différent. Tu as 15G sur / et 3 81G
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 opti on
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 :

Mais j'ai un / de 15 Go a cote ???

J.MOLIERE - Mentor/J



Le 25 septembre 2013 22:25, Belaïd
5% de tes 381 ~ 19 volés => les 5% réservé a root selon ma vis ion.



Le 25 septembre 2013 22:19, jerome moliere
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 écrit :

Salut,


C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

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"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesyste m
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taille
des block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais "du" est plus
significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Bel aïd
n'a pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

Bonsoir,
Quand tu crées un système de fichier sur un disque, un pourcent age
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 pe rmettre a
certaine applications critiques de continuer à s’exécuter et d onc 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 libre quand tu exécute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere
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

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

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






--
< Belaid >










--
< Belaid >









--
< Belaid >







--
< Belaid >







--001a11c381225df9d104e73cb598
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable





<div bgcolor="#FFFFFF" text="#000000">
<div>J&#39;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&#39;avenir alors c&#39;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&#39;info sur
tune2fs. <br>
<br>
En revanche c&#39;est lié aux partitions ext mais ce qui est biza rre
c&#39;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
&quot;only ext3/ext4&quot;<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&#39;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 &quot;adapté&quot; d&#39;utiliser
&quot;du&quot;<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&#39;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&#39;une
option de df, mais malheureusement je ne m&#39;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&#39;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
=&gt; 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&#39;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&#39;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&#39;est pas
visible par
&quot;du&quot;<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&#39;info à un
instant T
c&#39;est que tu
vois
maintenant<br>
du n&#39;inclut
pas les
fichiers
ouverts et ne
se base pas
sur la taille
des block<br>
<br>
et surement
bien d&#39;autres
différences<br>
<br>
Ces 2
commandes sont
très bonnes et
&quot;équivalen tes&quot;
mais &quot;du&quo t; est
plus
significative
dans l&#39;instan t
T<br>
<br>
ps : rien à
voir avec le
/root cité ci
dessous, je
pense que
Belaïd n&#39;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&#39;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 à
s’exécuter et
donc d&#39;évit er
de bloquer le
systéme. Cet
espace de 5%
dédié
(modifiable
avec la
commande
tune2fs) n&#39;es t
pas visible
comme étant de
l&#39;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&#39;ai n&#39;es t pas
sous Debian
mais je pense
qu&#39;il pourrai t
se poser.</div>
<div>Il est
sous Manjaro
(archlinux)</div>
<div>J&#39;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


~&gt; 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&#39;es t
pas grave mais
du coup je me
pose beaucoup
de questions
car mon /
pourrait vite
saturer s&#39;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&#39;il une autr e
methode pour
calculer
l&#39;espace disp o
?</div>
<div>Meme les
arrondis
n&#39;expliquent
pas de perdre
5% d&#39;espace
disque ainsi
...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid
&gt; </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>
&lt; Belaid &gt; </font></span> </div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
&lt; Belaid &gt; </div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
&lt; Belaid &gt; </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/
jerome moliere
Le #25686262
--089e0141a16e57fbb204e74b5e15
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
Lol bon tu sais se qui te reste a faire :-) .... laisse tombé la pin te et
met toi au jack ;-)
Le 25 sept. 2013 23:35, "Johnny B"
J'en profite pour dériver en HS, mais ext4 (qui a encore de beaux j ours)
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 ;)

voila pour le coup de provoc =)

Le 09/25/2013 11:26 PM, Johnny B a écrit :

Autant pour moi merci pour l'info sur tune2fs.

En revanche c'est lié aux partitions ext mais ce qui est bizarre c' est
que ext4 a un système de défrag online et de bloc allocator

https://wiki.archlinux.org/index.php/Ext4

Je ne constate pas le problème étant en xfs et tune2fs ét ant du "only
ext3/ext4"

Belle avancée ;)


Le 09/25/2013 11:11 PM, Belaïd a écrit :

man tune2fs, regarde l'option -m


Le 25 septembre 2013 23:05, Johnny B
Tu cherches a obtenir une info sur ton FS a un instant T donc déj à il
est plus "adapté" d'utiliser "du"

Ensuite je cherche le truc des 5% mais jamais entendu parler, je suis e n
xfs perso


Le 09/25/2013 10:51 PM, Belaïd a écrit :

/ 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 avo ir, 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 son t
dédié pour root. Si tu regarde tes 15G, logiquement tu aura l e même constat
que pour /home


Le 25 septembre 2013 22:37, jerome moliere écrit :

Mais j'ai un / de 15 Go a cote ???

J.MOLIERE - Mentor/J



Le 25 septembre 2013 22:25, Belaïd :

5% de tes 381 ~ 19 volés => les 5% réservé a root se lon ma vision.



Le 25 septembre 2013 22:19, jerome moliere
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 écrit :

Salut,


C'est juste les arguments que tu utilises pour ces 2 commandes qui
diffèrent dans les résultats.

Comme tu l a fait avec lsof on voit que certains process gardent de s
fichiers supprimés ouverts, ce qui n'est pas visible par "du"

De plus ces commandes calculent de différentes manières :

df prends la plupart des ses infos depuis le superblock du filesyst em
df inclu les fichiers ouverts

du remonte l'info à un instant T c'est que tu vois maintenant
du n'inclut pas les fichiers ouverts et ne se base pas sur la taill e
des block

et surement bien d'autres différences

Ces 2 commandes sont très bonnes et "équivalentes" mais " du" est
plus significative dans l'instant T

ps : rien à voir avec le /root cité ci dessous, je pense que Belaïd
n'a pas saisi ta question ;)


Le 09/25/2013 09:00 PM, Belaïd a écrit :

Bonsoir,
Quand tu crées un système de fichier sur un disque, un p ourcentage
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 disq ues, 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é (modif iable avec la commande
tune2fs) n'est pas visible comme étant de l'espace libre quand tu exécute
la commande df.


Le 25 septembre 2013 19:57, jerome moliere m
> a écrit :

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

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

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






--
< Belaid >










--
< Belaid >









--
< Belaid >







--
< Belaid >









--089e0141a16e57fbb204e74b5e15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable









<div bgcolor="#FFFFFF" text="#000000">
<div>J&#39;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&#39;avenir alors c&#39;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&#39;info sur
tune2fs. <br>
<br>
En revanche c&#39;est lié aux partitions ext mais ce qui est b izarre
c&#39;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
&quot;only ext3/ext4&quot;<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&#39;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 &quot;adaptà ©&quot; d&#39;utiliser
&quot;du&quot;<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&#39;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&#39;une
option de df, mais malheureusement je ne m&#39;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&#39;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
=&gt; 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&#39;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&#39;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&#39;est pas
visible par
&quot;du&quot;<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&#39;info à un
instant T
c&#39;est que tu
vois
maintenant<br>
du n&#39;inclut
pas les
fichiers
ouverts et ne
se base pas
sur la taille
des block<br>
<br>
et surement
bien d&#39;autres
différences< br>
<br>
Ces 2
commandes sont
très bonnes et
&quot;équiva lentes&quot;
mais &quot;du&quo t; est
plus
significative
dans l&#39;instan t
T<br>
<br>
ps : rien à
voir avec le
/root cité c i
dessous, je
pense que
Belaïd n&#39 ;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&#39;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&#39;é viter
de bloquer le
systéme. Cet
espace de 5%
dédié
(modifiable
avec la
commande
tune2fs) n&#39;es t
pas visible
comme étant de
l&#39;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&#39;ai n&#39;es t pas
sous Debian
mais je pense
qu&#39;il pourrai t
se poser.</div>
<div>Il est
sous Manjaro
(archlinux)</div>
<div>J&#39;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


~&gt; 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&#39;es t
pas grave mais
du coup je me
pose beaucoup
de questions
car mon /
pourrait vite
saturer s&#39;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&#39;il une autr e
methode pour
calculer
l&#39;espace disp o
?</div>
<div>Meme les
arrondis
n&#39;expliquent
pas de perdre
5% d&#39;espace
disque ainsi
...</div>
<div><br>
</div>
<div>J&#39;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&#39;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>
&lt; Belaid
&gt; </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>
&lt; Belaid &gt; </font></span> </div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
&lt; Belaid &gt; </div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
&lt; Belaid &gt; </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û
Publicité
Poster une réponse
Anonyme