J'ai regardé du côté du firmware s’il n'y avait pas une mise à jour.
Sur le site de seagate ça me dit que non mais si je recherche mon modèle
(ST2000DM001-1E6164) sur internet je vois une version de firmware CC45
alors que le mien est en CC28 ...
J'ai regardé du côté du firmware s’il n'y avait pas une mise à jour.
Sur le site de seagate ça me dit que non mais si je recherche mon modèle
(ST2000DM001-1E6164) sur internet je vois une version de firmware CC45
alors que le mien est en CC28 ...
J'ai regardé du côté du firmware s’il n'y avait pas une mise à jour.
Sur le site de seagate ça me dit que non mais si je recherche mon modèle
(ST2000DM001-1E6164) sur internet je vois une version de firmware CC45
alors que le mien est en CC28 ...
[â¦]
Si c'était un problème de firmware, j'aurais tendance à penser
que tu aurais des perfs pourries depuis le début ce qui n'est
pas le cas il me semble, non ?
[â¦]
Si c'était un problème de firmware, j'aurais tendance à penser
que tu aurais des perfs pourries depuis le début ce qui n'est
pas le cas il me semble, non ?
[â¦]
Si c'était un problème de firmware, j'aurais tendance à penser
que tu aurais des perfs pourries depuis le début ce qui n'est
pas le cas il me semble, non ?
[â¦]
Au passage, je suis surpris du temps %CPU utilisé pour les
écritures séquentielles en mode « par caractères » : 97% dans
mon cas et toi tu avais 79%. Alors qu'en mode par blocs par
exemple ça retombe à 7%. Si quelqu'un a une explication sur
ce phénomène, je serais curieux de la connaître.
[â¦]
Au passage, je suis surpris du temps %CPU utilisé pour les
écritures séquentielles en mode « par caractères » : 97% dans
mon cas et toi tu avais 79%. Alors qu'en mode par blocs par
exemple ça retombe à 7%. Si quelqu'un a une explication sur
ce phénomène, je serais curieux de la connaître.
[â¦]
Au passage, je suis surpris du temps %CPU utilisé pour les
écritures séquentielles en mode « par caractères » : 97% dans
mon cas et toi tu avais 79%. Alors qu'en mode par blocs par
exemple ça retombe à 7%. Si quelqu'un a une explication sur
ce phénomène, je serais curieux de la connaître.
Le Fri, 01 May 2015 14:48:20 +0200
mireero a écrit:On 05/01/2015 02:30 PM, Gaëtan PERRIER wrote:Tu peux aussi faire des tests d'écriture sur chacun de tes disquespour 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.
rien d'anormal en écriture:
dd if=/dev/zero of=/home/gpe/temp.zero bs=1M count000
10000+0 enregistrements lus
10000+0 enregistrements écrits
10485760000 octets (10 GB) copiés, 68,9717 s, 152 MB/s
en lecture je doute que ce test soit pertinent vu les perf qu'il indique:
dd if=/home/gpe/temp.zero of=/dev/null bs=1M count000
10000+0 enregistrements lus
10000+0 enregistrements écrits
10485760000 octets (10 GB) copiés, 1,01603 s, 10,3 GB/s
Gaëtan
Le Fri, 01 May 2015 14:48:20 +0200
mireero <mireero@free.fr> a écrit:
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.
rien d'anormal en écriture:
dd if=/dev/zero of=/home/gpe/temp.zero bs=1M count000
10000+0 enregistrements lus
10000+0 enregistrements écrits
10485760000 octets (10 GB) copiés, 68,9717 s, 152 MB/s
en lecture je doute que ce test soit pertinent vu les perf qu'il indique:
dd if=/home/gpe/temp.zero of=/dev/null bs=1M count000
10000+0 enregistrements lus
10000+0 enregistrements écrits
10485760000 octets (10 GB) copiés, 1,01603 s, 10,3 GB/s
Gaëtan
Le Fri, 01 May 2015 14:48:20 +0200
mireero a écrit:On 05/01/2015 02:30 PM, Gaëtan PERRIER wrote:Tu peux aussi faire des tests d'écriture sur chacun de tes disquespour 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.
rien d'anormal en écriture:
dd if=/dev/zero of=/home/gpe/temp.zero bs=1M count000
10000+0 enregistrements lus
10000+0 enregistrements écrits
10485760000 octets (10 GB) copiés, 68,9717 s, 152 MB/s
en lecture je doute que ce test soit pertinent vu les perf qu'il indique:
dd if=/home/gpe/temp.zero of=/dev/null bs=1M count000
10000+0 enregistrements lus
10000+0 enregistrements écrits
10485760000 octets (10 GB) copiés, 1,01603 s, 10,3 GB/s
Gaëtan
[â¦]
Bonnie++ donne quoi sur vos machines, histoire d'avoir un
point de comparaison ?
[â¦]
Bonnie++ donne quoi sur vos machines, histoire d'avoir un
point de comparaison ?
[â¦]
Bonnie++ donne quoi sur vos machines, histoire d'avoir un
point de comparaison ?
Au passage, je suis surpris du temps %CPU utilisé pour les écritures
séquentielles en mode « par caractères » : 97% dans mon cas et to i tu
avais 79%. Alors qu'en mode par blocs par exemple ça retombe à 7%. Si
quelqu'un a une explication sur ce phénomène, je serais curieux de la
connaître.
Bref, pour en revenir à ton problème, je trouve quand même curieux que
du jour au lendemain tu te retrouves avec des perfs pourries comme ça.
J'ai du mal à imaginer un problème matériel (mais j'ai peut-être tort)
et je pense que si tu avais fait des modifs particulières au niveau des
disques (genre options de montages etc.) tu n'aurais pas manqué de nous
le signaler.
Tu ne sais pas si tes problèmes de perfs sont apparues au
même moment qu'une mise à jour particulière ou qu'une install parti culière
par hasard ? À moins que l'apparition des perfs pourries se soient
faites petit à petit ?
N'y aurait-il pas un process qui tourne en arrière plan et qui sollicite
ton disque sans arrêt de sorte que ça te plombe tes I/O ?
Attention, il
ne faut pas se limiter à la partition /home de ton disque mais à bien
regarder sur toutes les partitions de ton disque. Parce que si une
partition se fait bourriner sans arrêt par un process ça va impacter
toutes les partition du disque forcément (vu qu'au final c'est la même
tête de lecture qui trinque).
Pour écarter ce genre d'hypothèse, perso,
je pense qu'à ta place je redémarrerais le système en mode « reco very »
avec juste une console root (le truc le plus minimaliste possible quoi),
ensuite je démonterais *toutes* les partitions du disque suspect, puis
je remonterais uniquement la partition /home mais au niveau d'un répert oire
différent de /home justement (par exemple /home_tmp) puis je tenterais un
nouveau test bonnie++ (exactement le même que celui que tu as déjà effectué
précédemment).
Je vois que ton disque contient les partitions /home, /tmp et /srv si je ne
dis pas de bêtise. Par exemple, /srv, il te sert à quelque chose ? Il y a des
trucs qui tournent là-dessus ?
Au passage, je suis surpris du temps %CPU utilisé pour les écritures
séquentielles en mode « par caractères » : 97% dans mon cas et to i tu
avais 79%. Alors qu'en mode par blocs par exemple ça retombe à 7%. Si
quelqu'un a une explication sur ce phénomène, je serais curieux de la
connaître.
Bref, pour en revenir à ton problème, je trouve quand même curieux que
du jour au lendemain tu te retrouves avec des perfs pourries comme ça.
J'ai du mal à imaginer un problème matériel (mais j'ai peut-être tort)
et je pense que si tu avais fait des modifs particulières au niveau des
disques (genre options de montages etc.) tu n'aurais pas manqué de nous
le signaler.
Tu ne sais pas si tes problèmes de perfs sont apparues au
même moment qu'une mise à jour particulière ou qu'une install parti culière
par hasard ? À moins que l'apparition des perfs pourries se soient
faites petit à petit ?
N'y aurait-il pas un process qui tourne en arrière plan et qui sollicite
ton disque sans arrêt de sorte que ça te plombe tes I/O ?
Attention, il
ne faut pas se limiter à la partition /home de ton disque mais à bien
regarder sur toutes les partitions de ton disque. Parce que si une
partition se fait bourriner sans arrêt par un process ça va impacter
toutes les partition du disque forcément (vu qu'au final c'est la même
tête de lecture qui trinque).
Pour écarter ce genre d'hypothèse, perso,
je pense qu'à ta place je redémarrerais le système en mode « reco very »
avec juste une console root (le truc le plus minimaliste possible quoi),
ensuite je démonterais *toutes* les partitions du disque suspect, puis
je remonterais uniquement la partition /home mais au niveau d'un répert oire
différent de /home justement (par exemple /home_tmp) puis je tenterais un
nouveau test bonnie++ (exactement le même que celui que tu as déjà effectué
précédemment).
Je vois que ton disque contient les partitions /home, /tmp et /srv si je ne
dis pas de bêtise. Par exemple, /srv, il te sert à quelque chose ? Il y a des
trucs qui tournent là-dessus ?
Au passage, je suis surpris du temps %CPU utilisé pour les écritures
séquentielles en mode « par caractères » : 97% dans mon cas et to i tu
avais 79%. Alors qu'en mode par blocs par exemple ça retombe à 7%. Si
quelqu'un a une explication sur ce phénomène, je serais curieux de la
connaître.
Bref, pour en revenir à ton problème, je trouve quand même curieux que
du jour au lendemain tu te retrouves avec des perfs pourries comme ça.
J'ai du mal à imaginer un problème matériel (mais j'ai peut-être tort)
et je pense que si tu avais fait des modifs particulières au niveau des
disques (genre options de montages etc.) tu n'aurais pas manqué de nous
le signaler.
Tu ne sais pas si tes problèmes de perfs sont apparues au
même moment qu'une mise à jour particulière ou qu'une install parti culière
par hasard ? À moins que l'apparition des perfs pourries se soient
faites petit à petit ?
N'y aurait-il pas un process qui tourne en arrière plan et qui sollicite
ton disque sans arrêt de sorte que ça te plombe tes I/O ?
Attention, il
ne faut pas se limiter à la partition /home de ton disque mais à bien
regarder sur toutes les partitions de ton disque. Parce que si une
partition se fait bourriner sans arrêt par un process ça va impacter
toutes les partition du disque forcément (vu qu'au final c'est la même
tête de lecture qui trinque).
Pour écarter ce genre d'hypothèse, perso,
je pense qu'à ta place je redémarrerais le système en mode « reco very »
avec juste une console root (le truc le plus minimaliste possible quoi),
ensuite je démonterais *toutes* les partitions du disque suspect, puis
je remonterais uniquement la partition /home mais au niveau d'un répert oire
différent de /home justement (par exemple /home_tmp) puis je tenterais un
nouveau test bonnie++ (exactement le même que celui que tu as déjà effectué
précédemment).
Je vois que ton disque contient les partitions /home, /tmp et /srv si je ne
dis pas de bêtise. Par exemple, /srv, il te sert à quelque chose ? Il y a des
trucs qui tournent là-dessus ?
Le vendredi 1 mai 2015, 21:50:54 Gaëtan PERRIER a écrit :
>[…]
> Bonnie++ donne quoi sur vos machines, histoire d'avoir un
> point de comparaison ?
De mes machines, je pense que celle-ci est comparable : 2x3 To
(>2 ans) en RAID-1, ext4, sur un poussif Athlon II (>5 ans),
Sid.
--8<-- csv --8<--
1.97,1.97,xxxx,1,1430494803,7672M,,791,96,107497,22,45049,12,4238,85,139473,21,378.6,17,16,,,,,
+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,
++
+,16276us,888ms,201ms,37010us,75011us,272ms,39846us,1142us,839us,274us,43us,344us
-->8--
Note : La valeur par défaut pour la taille des fichiers est de
8 Gio mais elle est automatiquement ajustée pour la RAM de la
machine. (Cf. mon exemple : 7672 Mio parce que la RAM est de
4 Gio. Sur une autre machine qui a seulement 256 Mio de RAM, la
valeur auto est de 488 Mio.)
Ça n’a pas beaucoup d’incidence sur les résultats mais c’est à
savoir pour ceux qui voudraient comparer au poil près.
Le vendredi 1 mai 2015, 21:50:54 Gaëtan PERRIER a écrit :
>[…]
> Bonnie++ donne quoi sur vos machines, histoire d'avoir un
> point de comparaison ?
De mes machines, je pense que celle-ci est comparable : 2x3 To
(>2 ans) en RAID-1, ext4, sur un poussif Athlon II (>5 ans),
Sid.
--8<-- csv --8<--
1.97,1.97,xxxx,1,1430494803,7672M,,791,96,107497,22,45049,12,4238,85,139473,21,378.6,17,16,,,,,
+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,
++
+,16276us,888ms,201ms,37010us,75011us,272ms,39846us,1142us,839us,274us,43us,344us
-->8--
Note : La valeur par défaut pour la taille des fichiers est de
8 Gio mais elle est automatiquement ajustée pour la RAM de la
machine. (Cf. mon exemple : 7672 Mio parce que la RAM est de
4 Gio. Sur une autre machine qui a seulement 256 Mio de RAM, la
valeur auto est de 488 Mio.)
Ça n’a pas beaucoup d’incidence sur les résultats mais c’est à
savoir pour ceux qui voudraient comparer au poil près.
Le vendredi 1 mai 2015, 21:50:54 Gaëtan PERRIER a écrit :
>[…]
> Bonnie++ donne quoi sur vos machines, histoire d'avoir un
> point de comparaison ?
De mes machines, je pense que celle-ci est comparable : 2x3 To
(>2 ans) en RAID-1, ext4, sur un poussif Athlon II (>5 ans),
Sid.
--8<-- csv --8<--
1.97,1.97,xxxx,1,1430494803,7672M,,791,96,107497,22,45049,12,4238,85,139473,21,378.6,17,16,,,,,
+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,
++
+,16276us,888ms,201ms,37010us,75011us,272ms,39846us,1142us,839us,274us,43us,344us
-->8--
Note : La valeur par défaut pour la taille des fichiers est de
8 Gio mais elle est automatiquement ajustée pour la RAM de la
machine. (Cf. mon exemple : 7672 Mio parce que la RAM est de
4 Gio. Sur une autre machine qui a seulement 256 Mio de RAM, la
valeur auto est de 488 Mio.)
Ça n’a pas beaucoup d’incidence sur les résultats mais c’est à
savoir pour ceux qui voudraient comparer au poil près.
On 05/01/2015 06:40 PM, Gaëtan PERRIER wrote:
> Le Fri, 01 May 2015 14:48:20 +0200
> mireero a écrit:
>
>> 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.
>>
>
> rien d'anormal en écriture:
> dd if=/dev/zero of=/home/gpe/temp.zero bs=1M count000
> 10000+0 enregistrements lus
> 10000+0 enregistrements écrits
> 10485760000 octets (10 GB) copiés, 68,9717 s, 152 MB/s
>
> en lecture je doute que ce test soit pertinent vu les perf qu'il indique:
> dd if=/home/gpe/temp.zero of=/dev/null bs=1M count000
> 10000+0 enregistrements lus
> 10000+0 enregistrements écrits
> 10485760000 octets (10 GB) copiés, 1,01603 s, 10,3 GB/s
>
> Gaëtan
>
Salut,
Je suis d'accord avec les autres avec les autres pour dire qu'ici "dd"
ne te sera pas d'une grande aide vu qu’apparemment ce sont les temps de
latence qui sont en cause (tu pourrais coder avec dd pour les mesurer si
l'envie t'en prenait).
Ceci étant dit, ton dernier résultat ma surpris alors j'ai lancé la
commande 2 fois:
dd if=temp.zero of=/dev/null bs=1M
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 10.3383 s, 101 MB/s
dd if=temp.zero of=/dev/null bs=1M
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.182041 s, 5.8 GB/s
Il semble que lors de la 2ème commande, le résultat soit toujours en
cache (soit 1Gb de 0 en mémoire soit le système est un peu plus
intelligent et à la manière de ce qui a été dit, il enregistre
l'information "il y a 1073741824 octets qui se suivent avec une valeur
nulle").
Par contre, écrire un 3 dans /proc/sys/vm/drop_caches ne me donne pas
satisfaction (ça change rien!), j'avoue mon ignorance ici.
Tu peux copier un autre fichier avec dd, pour éviter le résultat
ci-dessus, et pour éviter la suite de 0 si pour quelque raison elle
était gênante (j'éviterai /dev/urandom, le processeur devient le facteur
limitant dans ce cas, du moins chez moi), tu peux prendre une archive,
un divx...
On 05/01/2015 06:40 PM, Gaëtan PERRIER wrote:
> Le Fri, 01 May 2015 14:48:20 +0200
> mireero <mireero@free.fr> a écrit:
>
>> 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.
>>
>
> rien d'anormal en écriture:
> dd if=/dev/zero of=/home/gpe/temp.zero bs=1M count000
> 10000+0 enregistrements lus
> 10000+0 enregistrements écrits
> 10485760000 octets (10 GB) copiés, 68,9717 s, 152 MB/s
>
> en lecture je doute que ce test soit pertinent vu les perf qu'il indique:
> dd if=/home/gpe/temp.zero of=/dev/null bs=1M count000
> 10000+0 enregistrements lus
> 10000+0 enregistrements écrits
> 10485760000 octets (10 GB) copiés, 1,01603 s, 10,3 GB/s
>
> Gaëtan
>
Salut,
Je suis d'accord avec les autres avec les autres pour dire qu'ici "dd"
ne te sera pas d'une grande aide vu qu’apparemment ce sont les temps de
latence qui sont en cause (tu pourrais coder avec dd pour les mesurer si
l'envie t'en prenait).
Ceci étant dit, ton dernier résultat ma surpris alors j'ai lancé la
commande 2 fois:
dd if=temp.zero of=/dev/null bs=1M
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 10.3383 s, 101 MB/s
dd if=temp.zero of=/dev/null bs=1M
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.182041 s, 5.8 GB/s
Il semble que lors de la 2ème commande, le résultat soit toujours en
cache (soit 1Gb de 0 en mémoire soit le système est un peu plus
intelligent et à la manière de ce qui a été dit, il enregistre
l'information "il y a 1073741824 octets qui se suivent avec une valeur
nulle").
Par contre, écrire un 3 dans /proc/sys/vm/drop_caches ne me donne pas
satisfaction (ça change rien!), j'avoue mon ignorance ici.
Tu peux copier un autre fichier avec dd, pour éviter le résultat
ci-dessus, et pour éviter la suite de 0 si pour quelque raison elle
était gênante (j'éviterai /dev/urandom, le processeur devient le facteur
limitant dans ce cas, du moins chez moi), tu peux prendre une archive,
un divx...
On 05/01/2015 06:40 PM, Gaëtan PERRIER wrote:
> Le Fri, 01 May 2015 14:48:20 +0200
> mireero a écrit:
>
>> 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.
>>
>
> rien d'anormal en écriture:
> dd if=/dev/zero of=/home/gpe/temp.zero bs=1M count000
> 10000+0 enregistrements lus
> 10000+0 enregistrements écrits
> 10485760000 octets (10 GB) copiés, 68,9717 s, 152 MB/s
>
> en lecture je doute que ce test soit pertinent vu les perf qu'il indique:
> dd if=/home/gpe/temp.zero of=/dev/null bs=1M count000
> 10000+0 enregistrements lus
> 10000+0 enregistrements écrits
> 10485760000 octets (10 GB) copiés, 1,01603 s, 10,3 GB/s
>
> Gaëtan
>
Salut,
Je suis d'accord avec les autres avec les autres pour dire qu'ici "dd"
ne te sera pas d'une grande aide vu qu’apparemment ce sont les temps de
latence qui sont en cause (tu pourrais coder avec dd pour les mesurer si
l'envie t'en prenait).
Ceci étant dit, ton dernier résultat ma surpris alors j'ai lancé la
commande 2 fois:
dd if=temp.zero of=/dev/null bs=1M
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 10.3383 s, 101 MB/s
dd if=temp.zero of=/dev/null bs=1M
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.182041 s, 5.8 GB/s
Il semble que lors de la 2ème commande, le résultat soit toujours en
cache (soit 1Gb de 0 en mémoire soit le système est un peu plus
intelligent et à la manière de ce qui a été dit, il enregistre
l'information "il y a 1073741824 octets qui se suivent avec une valeur
nulle").
Par contre, écrire un 3 dans /proc/sys/vm/drop_caches ne me donne pas
satisfaction (ça change rien!), j'avoue mon ignorance ici.
Tu peux copier un autre fichier avec dd, pour éviter le résultat
ci-dessus, et pour éviter la suite de 0 si pour quelque raison elle
était gênante (j'éviterai /dev/urandom, le processeur devient le facteur
limitant dans ce cas, du moins chez moi), tu peux prendre une archive,
un divx...
[â¦]
C'est sur que du coup chez moi ça fait quand même un fichie r
de 32 Gio ...
[â¦]
C'est sur que du coup chez moi ça fait quand même un fichie r
de 32 Gio ...
[â¦]
C'est sur que du coup chez moi ça fait quand même un fichie r
de 32 Gio ...
Lecture par caractères : il y a des tampons, donc le disque
n’est sollicité que lorsque les tampons sont vides, pendant ce
temps-là, le CPU mouline à fond sur les tampons en les lisant
caractère par caractère. Le processus passe son temps à
travailler sur les caractères, pas en E/S.
Lecture par blocs : les tampons sont consommés plus vite,
voire immédiatement, le processus attend que les tampons soient
renouvelés, le CPU se repose. Le processus passe son temps en
E/S, pas en travail sur les blocs.
Lecture par caractères : il y a des tampons, donc le disque
n’est sollicité que lorsque les tampons sont vides, pendant ce
temps-là, le CPU mouline à fond sur les tampons en les lisant
caractère par caractère. Le processus passe son temps à
travailler sur les caractères, pas en E/S.
Lecture par blocs : les tampons sont consommés plus vite,
voire immédiatement, le processus attend que les tampons soient
renouvelés, le CPU se repose. Le processus passe son temps en
E/S, pas en travail sur les blocs.
Lecture par caractères : il y a des tampons, donc le disque
n’est sollicité que lorsque les tampons sont vides, pendant ce
temps-là, le CPU mouline à fond sur les tampons en les lisant
caractère par caractère. Le processus passe son temps à
travailler sur les caractères, pas en E/S.
Lecture par blocs : les tampons sont consommés plus vite,
voire immédiatement, le processus attend que les tampons soient
renouvelés, le CPU se repose. Le processus passe son temps en
E/S, pas en travail sur les blocs.