Le 01/05/2015 16:14, Sylvain L. Sauvage a écrit :et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
[...]3. La sortie est un fichier plein de zéros, donc, sur un système
de fichiers moderne, il n’y a rien d’écrit sur le disque (à part
une entrée qui dit que le fichier est plein de X zéros).
Tu es sûr de ça ? Par exemple, sur ma Debian Wheezy j'ai :
-------------------------------------------------
~$ echo Salut > /tmp/out
~$ od -Ad -x /tmp/out
0000000 6153 756c 0a74
0000006
~$ dd if=/dev/zero of=/tmp/out bs0c count=1
1+0 enregistrements lus
1+0 enregistrements écrits
100 octets (100 B) copiés, 9,6205e-05 s, 1,0 MB/s
~$ od -Ad -v -x /tmp/out
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000016 0000 0000 0000 0000 0000 0000 0000 0000
0000032 0000 0000 0000 0000 0000 0000 0000 0000
0000048 0000 0000 0000 0000 0000 0000 0000 0000
0000064 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000096 0000 0000
0000100
-------------------------------------------------
sachant que /tmp se trouve sur ma partition racine qui est en ext4.
À moins que ext4 ne soit peut-être pas assez « moderne » pour supporter
la fonctionnalité dont tu parles ? Ou alors c'est la commande od qui
ne m'indique pas le contenu du fichier tel qu'il est réellement ?
Le 01/05/2015 16:14, Sylvain L. Sauvage a écrit :
et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
[...]
3. La sortie est un fichier plein de zéros, donc, sur un système
de fichiers moderne, il n’y a rien d’écrit sur le disque (à part
une entrée qui dit que le fichier est plein de X zéros).
Tu es sûr de ça ? Par exemple, sur ma Debian Wheezy j'ai :
-------------------------------------------------
~$ echo Salut > /tmp/out
~$ od -Ad -x /tmp/out
0000000 6153 756c 0a74
0000006
~$ dd if=/dev/zero of=/tmp/out bs0c count=1
1+0 enregistrements lus
1+0 enregistrements écrits
100 octets (100 B) copiés, 9,6205e-05 s, 1,0 MB/s
~$ od -Ad -v -x /tmp/out
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000016 0000 0000 0000 0000 0000 0000 0000 0000
0000032 0000 0000 0000 0000 0000 0000 0000 0000
0000048 0000 0000 0000 0000 0000 0000 0000 0000
0000064 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000096 0000 0000
0000100
-------------------------------------------------
sachant que /tmp se trouve sur ma partition racine qui est en ext4.
À moins que ext4 ne soit peut-être pas assez « moderne » pour supporter
la fonctionnalité dont tu parles ? Ou alors c'est la commande od qui
ne m'indique pas le contenu du fichier tel qu'il est réellement ?
Le 01/05/2015 16:14, Sylvain L. Sauvage a écrit :et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
[...]3. La sortie est un fichier plein de zéros, donc, sur un système
de fichiers moderne, il n’y a rien d’écrit sur le disque (à part
une entrée qui dit que le fichier est plein de X zéros).
Tu es sûr de ça ? Par exemple, sur ma Debian Wheezy j'ai :
-------------------------------------------------
~$ echo Salut > /tmp/out
~$ od -Ad -x /tmp/out
0000000 6153 756c 0a74
0000006
~$ dd if=/dev/zero of=/tmp/out bs0c count=1
1+0 enregistrements lus
1+0 enregistrements écrits
100 octets (100 B) copiés, 9,6205e-05 s, 1,0 MB/s
~$ od -Ad -v -x /tmp/out
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000016 0000 0000 0000 0000 0000 0000 0000 0000
0000032 0000 0000 0000 0000 0000 0000 0000 0000
0000048 0000 0000 0000 0000 0000 0000 0000 0000
0000064 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000096 0000 0000
0000100
-------------------------------------------------
sachant que /tmp se trouve sur ma partition racine qui est en ext4.
À moins que ext4 ne soit peut-être pas assez « moderne » pour supporter
la fonctionnalité dont tu parles ? Ou alors c'est la commande od qui
ne m'indique pas le contenu du fichier tel qu'il est réellement ?
Je vois beaucoup d'await (>300 voir même 1000) sur sdb5 et 7 soit /home et /tmp
quand je ferme gthumb par exemple.
Je vois beaucoup d'await (>300 voir même 1000) sur sdb5 et 7 soit /home et /tmp
quand je ferme gthumb par exemple.
Je vois beaucoup d'await (>300 voir même 1000) sur sdb5 et 7 soit /home et /tmp
quand je ferme gthumb par exemple.
Le 01/05/2015 16:59, Gaëtan PERRIER a écrit :
> Je vois beaucoup d'await (>300 voir même 1000) sur sdb5 et 7 soit /ho me
> et /tmp quand je ferme gthumb par exemple.
Je doute fort que ce soit la cause de tes soucis mais je vois l'option
de montage "relatime" sur tes partitions /home et /tmp. As-tu vraiment
besoin du atime ? En général il est inutile et peut diminuer les perf s.
Perso, sur du ext4 je mets en général "noatime,defaults" comme options
de montage.
Le 01/05/2015 16:59, Gaëtan PERRIER a écrit :
> Je vois beaucoup d'await (>300 voir même 1000) sur sdb5 et 7 soit /ho me
> et /tmp quand je ferme gthumb par exemple.
Je doute fort que ce soit la cause de tes soucis mais je vois l'option
de montage "relatime" sur tes partitions /home et /tmp. As-tu vraiment
besoin du atime ? En général il est inutile et peut diminuer les perf s.
Perso, sur du ext4 je mets en général "noatime,defaults" comme options
de montage.
Le 01/05/2015 16:59, Gaëtan PERRIER a écrit :
> Je vois beaucoup d'await (>300 voir même 1000) sur sdb5 et 7 soit /ho me
> et /tmp quand je ferme gthumb par exemple.
Je doute fort que ce soit la cause de tes soucis mais je vois l'option
de montage "relatime" sur tes partitions /home et /tmp. As-tu vraiment
besoin du atime ? En général il est inutile et peut diminuer les perf s.
Perso, sur du ext4 je mets en général "noatime,defaults" comme options
de montage.
Le vendredi 1 mai 2015, 15:13:49 Gaëtan PERRIER a écrit :[…]et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
Oui mais tu mesures comment ?
Une fois fini, dd t’indique le nombre de blocs et d’octets
écrits, le temps écoulé et le débit.
De légers problèmes avec la commande indiquée :
1. il n’y a pas d’option count, donc ça ne termine pas. Ça peut
se défendre si on veut voir ce qu’il se passe sur le disque
pendant que dd fait son boulot…
2. La source est virtuelle, donc on ne teste pas la lecture.
3. La sortie est un fichier plein de zéros, donc, sur un système
de fichiers moderne, il n’y a rien d’écrit sur le disque (à part
une entrée qui dit que le fichier est plein de X zéros).
En résumé : ça ne lit rien, ça n’écrit rien et ça ne s’arrête
pas.
Pour ton problème, tu as vérifié/modifié les paramètres hdparm
(mise en veille…) ?
Le vendredi 1 mai 2015, 15:13:49 Gaëtan PERRIER a écrit :
[…]
et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
Oui mais tu mesures comment ?
Une fois fini, dd t’indique le nombre de blocs et d’octets
écrits, le temps écoulé et le débit.
De légers problèmes avec la commande indiquée :
1. il n’y a pas d’option count, donc ça ne termine pas. Ça peut
se défendre si on veut voir ce qu’il se passe sur le disque
pendant que dd fait son boulot…
2. La source est virtuelle, donc on ne teste pas la lecture.
3. La sortie est un fichier plein de zéros, donc, sur un système
de fichiers moderne, il n’y a rien d’écrit sur le disque (à part
une entrée qui dit que le fichier est plein de X zéros).
En résumé : ça ne lit rien, ça n’écrit rien et ça ne s’arrête
pas.
Pour ton problème, tu as vérifié/modifié les paramètres hdparm
(mise en veille…) ?
Le vendredi 1 mai 2015, 15:13:49 Gaëtan PERRIER a écrit :[…]et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
Oui mais tu mesures comment ?
Une fois fini, dd t’indique le nombre de blocs et d’octets
écrits, le temps écoulé et le débit.
De légers problèmes avec la commande indiquée :
1. il n’y a pas d’option count, donc ça ne termine pas. Ça peut
se défendre si on veut voir ce qu’il se passe sur le disque
pendant que dd fait son boulot…
2. La source est virtuelle, donc on ne teste pas la lecture.
3. La sortie est un fichier plein de zéros, donc, sur un système
de fichiers moderne, il n’y a rien d’écrit sur le disque (à part
une entrée qui dit que le fichier est plein de X zéros).
En résumé : ça ne lit rien, ça n’écrit rien et ça ne s’arrête
pas.
Pour ton problème, tu as vérifié/modifié les paramètres hdparm
(mise en veille…) ?
On 05/01/2015 02:30 PM, Gaëtan PERRIER wrote:
>> Tu peux aussi faire des tests d'écriture sur chacun de tes disques
>> >pour te faire une comparaison?
> De quelle manière ?
Peut-être hdparm -tT /dev/disk
et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
J'imagine qu'il y a mieux comme benchmark mais ça pourrait être un d ébut.
On 05/01/2015 02:30 PM, Gaëtan PERRIER wrote:
>> Tu peux aussi faire des tests d'écriture sur chacun de tes disques
>> >pour te faire une comparaison?
> De quelle manière ?
Peut-être hdparm -tT /dev/disk
et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
J'imagine qu'il y a mieux comme benchmark mais ça pourrait être un d ébut.
On 05/01/2015 02:30 PM, Gaëtan PERRIER wrote:
>> Tu peux aussi faire des tests d'écriture sur chacun de tes disques
>> >pour te faire une comparaison?
> De quelle manière ?
Peut-être hdparm -tT /dev/disk
et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).
J'imagine qu'il y a mieux comme benchmark mais ça pourrait être un d ébut.
Deuxième solution : od demande les octets au filesystem, qui va lui
donner autant de zéro que nécessaire.
Il faudrait aller voir directement dans les blocs du disque.
Deuxième solution : od demande les octets au filesystem, qui va lui
donner autant de zéro que nécessaire.
Il faudrait aller voir directement dans les blocs du disque.
Deuxième solution : od demande les octets au filesystem, qui va lui
donner autant de zéro que nécessaire.
Il faudrait aller voir directement dans les blocs du disque.
[â¦]
en pièce jointe le résultat de bonnie++ mais je ne sais pas
trop comment ça s'interprète ?
[â¦]
en pièce jointe le résultat de bonnie++ mais je ne sais pas
trop comment ça s'interprète ?
[â¦]
en pièce jointe le résultat de bonnie++ mais je ne sais pas
trop comment ça s'interprète ?
’soir,
Sur ce que j’ai dit avant (fichiers à trous, plein de zéros) :
http://en.wikipedia.org/wiki/Sparse_file
En revanche, le dd tel que proposé n’en crée pas. Mea culpa.
(Mais ça n’empêche pas que c’est un test qui n’indique pas
grand-chose :oP )
Pour ceux que veulent savoir si un fichier occupe réellement
de la place sur le disque, voir l’option -k de ls :
ls -lks indique le nombre de blocs utilisés en première colonne.
Le vendredi 1 mai 2015, 17:57:29 Gaëtan PERRIER a écrit :
>[…]
> en pièce jointe le résultat de bonnie++ mais je ne sais pas
> trop comment ça s'interprète ?
Explication des tests :
→ /usr/share/doc/bonnie++/readme.html
Pour chaque test (man bonnie++) :
For every test two numbers are reported, the amount of
work done (higher numbers are better) and the percentage
of CPU time taken to perform the work (lower numbers are
better). If a test completes in less than 500ms then the
output will be displayed as "++++". This is because
such a test result can't be calculated accurately due to
rounding errors and I would rather display no result than
a wrong result.
Les résultats sont dans un tableau ascii.
Tu peux prendre les lignes pleines de virgules à la fin et les
passer par bon_csv2html pour avoir un tableau un peu plus
lisible en HTML.
Comme pour beaucoup de résultats, ce qui est le plus
intéressant, c’est de comparer avant/après ou deux systèmes
proches.
De ce que j’en peux dire, tes chiffres m’ont l’air corrects
pour les débits (~100 Mio/s en écriture, ~200 Mio/s en lecture
et très peu d’usage du CPU) mais énormes pour les latences (1 à
2 secondes !).
Donc tu aurais un gros problème de latence (temps d’accès). Ce
qui est très très embêtant quand on lit/écrit beaucoup de
fichiers (genre une installation).
Bon, maintenant, il faut trouver d’où ça vient…
’soir,
Sur ce que j’ai dit avant (fichiers à trous, plein de zéros) :
http://en.wikipedia.org/wiki/Sparse_file
En revanche, le dd tel que proposé n’en crée pas. Mea culpa.
(Mais ça n’empêche pas que c’est un test qui n’indique pas
grand-chose :oP )
Pour ceux que veulent savoir si un fichier occupe réellement
de la place sur le disque, voir l’option -k de ls :
ls -lks indique le nombre de blocs utilisés en première colonne.
Le vendredi 1 mai 2015, 17:57:29 Gaëtan PERRIER a écrit :
>[…]
> en pièce jointe le résultat de bonnie++ mais je ne sais pas
> trop comment ça s'interprète ?
Explication des tests :
→ /usr/share/doc/bonnie++/readme.html
Pour chaque test (man bonnie++) :
For every test two numbers are reported, the amount of
work done (higher numbers are better) and the percentage
of CPU time taken to perform the work (lower numbers are
better). If a test completes in less than 500ms then the
output will be displayed as "++++". This is because
such a test result can't be calculated accurately due to
rounding errors and I would rather display no result than
a wrong result.
Les résultats sont dans un tableau ascii.
Tu peux prendre les lignes pleines de virgules à la fin et les
passer par bon_csv2html pour avoir un tableau un peu plus
lisible en HTML.
Comme pour beaucoup de résultats, ce qui est le plus
intéressant, c’est de comparer avant/après ou deux systèmes
proches.
De ce que j’en peux dire, tes chiffres m’ont l’air corrects
pour les débits (~100 Mio/s en écriture, ~200 Mio/s en lecture
et très peu d’usage du CPU) mais énormes pour les latences (1 à
2 secondes !).
Donc tu aurais un gros problème de latence (temps d’accès). Ce
qui est très très embêtant quand on lit/écrit beaucoup de
fichiers (genre une installation).
Bon, maintenant, il faut trouver d’où ça vient…
’soir,
Sur ce que j’ai dit avant (fichiers à trous, plein de zéros) :
http://en.wikipedia.org/wiki/Sparse_file
En revanche, le dd tel que proposé n’en crée pas. Mea culpa.
(Mais ça n’empêche pas que c’est un test qui n’indique pas
grand-chose :oP )
Pour ceux que veulent savoir si un fichier occupe réellement
de la place sur le disque, voir l’option -k de ls :
ls -lks indique le nombre de blocs utilisés en première colonne.
Le vendredi 1 mai 2015, 17:57:29 Gaëtan PERRIER a écrit :
>[…]
> en pièce jointe le résultat de bonnie++ mais je ne sais pas
> trop comment ça s'interprète ?
Explication des tests :
→ /usr/share/doc/bonnie++/readme.html
Pour chaque test (man bonnie++) :
For every test two numbers are reported, the amount of
work done (higher numbers are better) and the percentage
of CPU time taken to perform the work (lower numbers are
better). If a test completes in less than 500ms then the
output will be displayed as "++++". This is because
such a test result can't be calculated accurately due to
rounding errors and I would rather display no result than
a wrong result.
Les résultats sont dans un tableau ascii.
Tu peux prendre les lignes pleines de virgules à la fin et les
passer par bon_csv2html pour avoir un tableau un peu plus
lisible en HTML.
Comme pour beaucoup de résultats, ce qui est le plus
intéressant, c’est de comparer avant/après ou deux systèmes
proches.
De ce que j’en peux dire, tes chiffres m’ont l’air corrects
pour les débits (~100 Mio/s en écriture, ~200 Mio/s en lecture
et très peu d’usage du CPU) mais énormes pour les latences (1 à
2 secondes !).
Donc tu aurais un gros problème de latence (temps d’accès). Ce
qui est très très embêtant quand on lit/écrit beaucoup de
fichiers (genre une installation).
Bon, maintenant, il faut trouver d’où ça vient…
Je sens que ça ne va pas être simple :(
Bonnie++ donne quoi sur vos machines, histoire d'avoir un point de
comparaison ?
Je sens que ça ne va pas être simple :(
Bonnie++ donne quoi sur vos machines, histoire d'avoir un point de
comparaison ?
Je sens que ça ne va pas être simple :(
Bonnie++ donne quoi sur vos machines, histoire d'avoir un point de
comparaison ?