Faudrait surtout passer a autre chose
qu'ext4 parce que jouer avec ses blocs c'est juste dangereux
Moi j me suis mis au Jack c'est comme XFS c'est mieux ;)
Le 09/26/2013 05:52 PM, jerome moliere a écrit :
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 .
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 ;)
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
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
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
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 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'est
pas visible
comme étant de
l'espace libre
quand tu
exécute la
commande df.
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
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