il se reboote regulierement avec le planifica
il se reboote regulierement avec le planifica
il se reboote regulierement avec le planifica
Yliur a écrit :
>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>> comme il n'y a pas d'outils...
>>>
>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>> tout les systemes existant, mais je sais que c'est bien utile en
>> video, vu la taille des fichiers...
>
> Je ne vois pas le lien entre la taille des fichiers et le problème
> de fragmentation dans tes propos.
La fragmentation de l'espace libre?
Yliur a écrit :
>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>> comme il n'y a pas d'outils...
>>>
>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>> tout les systemes existant, mais je sais que c'est bien utile en
>> video, vu la taille des fichiers...
>
> Je ne vois pas le lien entre la taille des fichiers et le problème
> de fragmentation dans tes propos.
La fragmentation de l'espace libre?
Yliur a écrit :
>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>> comme il n'y a pas d'outils...
>>>
>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>> tout les systemes existant, mais je sais que c'est bien utile en
>> video, vu la taille des fichiers...
>
> Je ne vois pas le lien entre la taille des fichiers et le problème
> de fragmentation dans tes propos.
La fragmentation de l'espace libre?
Yliur a écrit :
> Le Thu, 15 Apr 2010 10:30:52 +0200
> Jerome Lambert a écrit :
>
>> Yliur a écrit :
>>>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>>>> comme il n'y a pas d'outils...
>>>>>
>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>>>> tout les systemes existant, mais je sais que c'est bien utile en
>>>> video, vu la taille des fichiers...
>>> Je ne vois pas le lien entre la taille des fichiers et le problème
>>> de fragmentation dans tes propos.
>> La fragmentation de l'espace libre?
>
> Oui mais il faut lire la suite aussi.
Qui explique le problème que pose la fragmentation pour la lecture de
fichiers, alors que la fragmentation de l'espace libre pose des
problèmes pour l'écriture.
Yliur a écrit :
> Le Thu, 15 Apr 2010 10:30:52 +0200
> Jerome Lambert <jerome.lambert@swing.be> a écrit :
>
>> Yliur a écrit :
>>>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>>>> comme il n'y a pas d'outils...
>>>>>
>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>>>> tout les systemes existant, mais je sais que c'est bien utile en
>>>> video, vu la taille des fichiers...
>>> Je ne vois pas le lien entre la taille des fichiers et le problème
>>> de fragmentation dans tes propos.
>> La fragmentation de l'espace libre?
>
> Oui mais il faut lire la suite aussi.
Qui explique le problème que pose la fragmentation pour la lecture de
fichiers, alors que la fragmentation de l'espace libre pose des
problèmes pour l'écriture.
Yliur a écrit :
> Le Thu, 15 Apr 2010 10:30:52 +0200
> Jerome Lambert a écrit :
>
>> Yliur a écrit :
>>>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>>>> comme il n'y a pas d'outils...
>>>>>
>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>>>> tout les systemes existant, mais je sais que c'est bien utile en
>>>> video, vu la taille des fichiers...
>>> Je ne vois pas le lien entre la taille des fichiers et le problème
>>> de fragmentation dans tes propos.
>> La fragmentation de l'espace libre?
>
> Oui mais il faut lire la suite aussi.
Qui explique le problème que pose la fragmentation pour la lecture de
fichiers, alors que la fragmentation de l'espace libre pose des
problèmes pour l'écriture.
Yliur a écrit :
>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>> comme il n'y a pas d'outils...
>>>
>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>> tout les systemes existant, mais je sais que c'est bien utile en
>> video, vu la taille des fichiers...
>
> Je ne vois pas le lien entre la taille des fichiers et le problème de
> fragmentation dans tes propos.
La fragmentation de l'espace libre?
Yliur a écrit :
>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>> comme il n'y a pas d'outils...
>>>
>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>> tout les systemes existant, mais je sais que c'est bien utile en
>> video, vu la taille des fichiers...
>
> Je ne vois pas le lien entre la taille des fichiers et le problème de
> fragmentation dans tes propos.
La fragmentation de l'espace libre?
Yliur a écrit :
>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
>>> comme il n'y a pas d'outils...
>>>
>> moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
>> tout les systemes existant, mais je sais que c'est bien utile en
>> video, vu la taille des fichiers...
>
> Je ne vois pas le lien entre la taille des fichiers et le problème de
> fragmentation dans tes propos.
La fragmentation de l'espace libre?
Jerome Lambert wrote:Yliur a écrit :c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
comme il n'y a pas d'outils...
moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
tout les systemes existant, mais je sais que c'est bien utile en
video, vu la taille des fichiers...
Je ne vois pas le lien entre la taille des fichiers et le problème de
fragmentation dans tes propos.
La fragmentation de l'espace libre?
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Jerome Lambert <jerome.lambert@swing.be> wrote:
Yliur a écrit :
c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
comme il n'y a pas d'outils...
moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
tout les systemes existant, mais je sais que c'est bien utile en
video, vu la taille des fichiers...
Je ne vois pas le lien entre la taille des fichiers et le problème de
fragmentation dans tes propos.
La fragmentation de l'espace libre?
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Jerome Lambert wrote:Yliur a écrit :c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS, mais
comme il n'y a pas d'outils...
moué, je n'en sais rien, je suis pas spécialiste de la défrag sur
tout les systemes existant, mais je sais que c'est bien utile en
video, vu la taille des fichiers...
Je ne vois pas le lien entre la taille des fichiers et le problème de
fragmentation dans tes propos.
La fragmentation de l'espace libre?
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Yliur a écrit :
> Le Thu, 15 Apr 2010 15:26:13 +0200
> Jerome Lambert a écrit :
>
>> Yliur a écrit :
>>> Le Thu, 15 Apr 2010 10:30:52 +0200
>>> Jerome Lambert a écrit :
>>>
>>>> Yliur a écrit :
>>>>>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS,
>>>>>>> mais comme il n'y a pas d'outils...
>>>>>>>
>>>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag
>>>>>> sur tout les systemes existant, mais je sais que c'est bien
>>>>>> utile en video, vu la taille des fichiers...
>>>>> Je ne vois pas le lien entre la taille des fichiers et le
>>>>> problème de fragmentation dans tes propos.
>>>> La fragmentation de l'espace libre?
>>> Oui mais il faut lire la suite aussi.
>> Qui explique le problème que pose la fragmentation pour la lecture
>> de fichiers, alors que la fragmentation de l'espace libre pose des
>> problèmes pour l'écriture.
>
> Le problème (de perte de temps) est le même. Si tu as manipules de
> gros fichiers et que SF est un peu malin, tu ne te retrouves pas
> avec des confettis. C'est aussi ça qui évite aux fichiers d'être
> fragmentés. Ce n'est pas un problème différent.
Si, dans le sens où même si tu n'as aucun fichier fragmenté mais que
tu crées un nouveau fichier dont la taille est supérieur au plus
grand espace contigu libre, tu auras une dégradation de performances
en écriture. De ce fait, pour la création de gros volumes de données
style acquisition vidéo en HD, il peut être intéressant de
défragmenter l'espace libre, quel que soit le FS utilisé.
Voir p.ex. la fin de http://support.apple.com/kb/ht1375 , et je me
souviens d'un notice d'une SGI il y a plus de 10 ans qui allait dans
le même sens.
Yliur a écrit :
> Le Thu, 15 Apr 2010 15:26:13 +0200
> Jerome Lambert <jerome.lambert@swing.be> a écrit :
>
>> Yliur a écrit :
>>> Le Thu, 15 Apr 2010 10:30:52 +0200
>>> Jerome Lambert <jerome.lambert@swing.be> a écrit :
>>>
>>>> Yliur a écrit :
>>>>>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS,
>>>>>>> mais comme il n'y a pas d'outils...
>>>>>>>
>>>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag
>>>>>> sur tout les systemes existant, mais je sais que c'est bien
>>>>>> utile en video, vu la taille des fichiers...
>>>>> Je ne vois pas le lien entre la taille des fichiers et le
>>>>> problème de fragmentation dans tes propos.
>>>> La fragmentation de l'espace libre?
>>> Oui mais il faut lire la suite aussi.
>> Qui explique le problème que pose la fragmentation pour la lecture
>> de fichiers, alors que la fragmentation de l'espace libre pose des
>> problèmes pour l'écriture.
>
> Le problème (de perte de temps) est le même. Si tu as manipules de
> gros fichiers et que SF est un peu malin, tu ne te retrouves pas
> avec des confettis. C'est aussi ça qui évite aux fichiers d'être
> fragmentés. Ce n'est pas un problème différent.
Si, dans le sens où même si tu n'as aucun fichier fragmenté mais que
tu crées un nouveau fichier dont la taille est supérieur au plus
grand espace contigu libre, tu auras une dégradation de performances
en écriture. De ce fait, pour la création de gros volumes de données
style acquisition vidéo en HD, il peut être intéressant de
défragmenter l'espace libre, quel que soit le FS utilisé.
Voir p.ex. la fin de http://support.apple.com/kb/ht1375 , et je me
souviens d'un notice d'une SGI il y a plus de 10 ans qui allait dans
le même sens.
Yliur a écrit :
> Le Thu, 15 Apr 2010 15:26:13 +0200
> Jerome Lambert a écrit :
>
>> Yliur a écrit :
>>> Le Thu, 15 Apr 2010 10:30:52 +0200
>>> Jerome Lambert a écrit :
>>>
>>>> Yliur a écrit :
>>>>>>> c'EST UN BOUFFON, EXT 3 fragmente au moins autant que NTFS,
>>>>>>> mais comme il n'y a pas d'outils...
>>>>>>>
>>>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag
>>>>>> sur tout les systemes existant, mais je sais que c'est bien
>>>>>> utile en video, vu la taille des fichiers...
>>>>> Je ne vois pas le lien entre la taille des fichiers et le
>>>>> problème de fragmentation dans tes propos.
>>>> La fragmentation de l'espace libre?
>>> Oui mais il faut lire la suite aussi.
>> Qui explique le problème que pose la fragmentation pour la lecture
>> de fichiers, alors que la fragmentation de l'espace libre pose des
>> problèmes pour l'écriture.
>
> Le problème (de perte de temps) est le même. Si tu as manipules de
> gros fichiers et que SF est un peu malin, tu ne te retrouves pas
> avec des confettis. C'est aussi ça qui évite aux fichiers d'être
> fragmentés. Ce n'est pas un problème différent.
Si, dans le sens où même si tu n'as aucun fichier fragmenté mais que
tu crées un nouveau fichier dont la taille est supérieur au plus
grand espace contigu libre, tu auras une dégradation de performances
en écriture. De ce fait, pour la création de gros volumes de données
style acquisition vidéo en HD, il peut être intéressant de
défragmenter l'espace libre, quel que soit le FS utilisé.
Voir p.ex. la fin de http://support.apple.com/kb/ht1375 , et je me
souviens d'un notice d'une SGI il y a plus de 10 ans qui allait dans
le même sens.
Le 15/04/2010 18:43, Yliur a écrit :
(...)
>>>>>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag
>>>>>>>> sur tout les systemes existant, mais je sais que c'est bien
>>>>>>>> utile en video, vu la taille des fichiers...
>>>>>>> Je ne vois pas le lien entre la taille des fichiers et le
>>>>>>> problème de fragmentation dans tes propos.
(...)
> Le problème est le même que pour la lecture : le boulot d'un sf malin
> est de copier ton gros fichier en gros blocs. Peu importe que ton
> fichier de 20Go soit en 3 parties, que ce soit en lecture ou en
> écriture.
Certes, mais on parlait de lien entre taille des fichiers et
fragmentation, et là clairement, plus le fichier est gros, plus la
probabilité qu'il doive être découpé en blocs est grande, et la seule
possibilité pour réduire ce risque est de défragmenter l'espace libre.
Et cela est valable quel que soit le SF utilisé.
Le 15/04/2010 18:43, Yliur a écrit :
(...)
>>>>>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag
>>>>>>>> sur tout les systemes existant, mais je sais que c'est bien
>>>>>>>> utile en video, vu la taille des fichiers...
>>>>>>> Je ne vois pas le lien entre la taille des fichiers et le
>>>>>>> problème de fragmentation dans tes propos.
(...)
> Le problème est le même que pour la lecture : le boulot d'un sf malin
> est de copier ton gros fichier en gros blocs. Peu importe que ton
> fichier de 20Go soit en 3 parties, que ce soit en lecture ou en
> écriture.
Certes, mais on parlait de lien entre taille des fichiers et
fragmentation, et là clairement, plus le fichier est gros, plus la
probabilité qu'il doive être découpé en blocs est grande, et la seule
possibilité pour réduire ce risque est de défragmenter l'espace libre.
Et cela est valable quel que soit le SF utilisé.
Le 15/04/2010 18:43, Yliur a écrit :
(...)
>>>>>>>> moué, je n'en sais rien, je suis pas spécialiste de la défrag
>>>>>>>> sur tout les systemes existant, mais je sais que c'est bien
>>>>>>>> utile en video, vu la taille des fichiers...
>>>>>>> Je ne vois pas le lien entre la taille des fichiers et le
>>>>>>> problème de fragmentation dans tes propos.
(...)
> Le problème est le même que pour la lecture : le boulot d'un sf malin
> est de copier ton gros fichier en gros blocs. Peu importe que ton
> fichier de 20Go soit en 3 parties, que ce soit en lecture ou en
> écriture.
Certes, mais on parlait de lien entre taille des fichiers et
fragmentation, et là clairement, plus le fichier est gros, plus la
probabilité qu'il doive être découpé en blocs est grande, et la seule
possibilité pour réduire ce risque est de défragmenter l'espace libre.
Et cela est valable quel que soit le SF utilisé.
En outre un facteur essentiel dont on n'a pas parlé jusqu'à présent,
c'est que tu as affaire à un système multitâche. Il n'y a pas que ton
job qui s'exécute et qui doit aller le plus vite possible, il y en a
d'autres, simultanés, qui lisent d'autres fichiers ailleurs sur le
disque. Au total le bras va quand même se promener sur le disque et,
bien sûr, l'OS va intercaler les demandes de lecture et d'écriture des
différents programmes en fonction de la position de la tête de lecture
(algorithme de l'ascenseur).
En outre un facteur essentiel dont on n'a pas parlé jusqu'à présent,
c'est que tu as affaire à un système multitâche. Il n'y a pas que ton
job qui s'exécute et qui doit aller le plus vite possible, il y en a
d'autres, simultanés, qui lisent d'autres fichiers ailleurs sur le
disque. Au total le bras va quand même se promener sur le disque et,
bien sûr, l'OS va intercaler les demandes de lecture et d'écriture des
différents programmes en fonction de la position de la tête de lecture
(algorithme de l'ascenseur).
En outre un facteur essentiel dont on n'a pas parlé jusqu'à présent,
c'est que tu as affaire à un système multitâche. Il n'y a pas que ton
job qui s'exécute et qui doit aller le plus vite possible, il y en a
d'autres, simultanés, qui lisent d'autres fichiers ailleurs sur le
disque. Au total le bras va quand même se promener sur le disque et,
bien sûr, l'OS va intercaler les demandes de lecture et d'écriture des
différents programmes en fonction de la position de la tête de lecture
(algorithme de l'ascenseur).
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Le 16/04/2010 09:53, Michel Talon a écrit :
> En outre un facteur essentiel dont on n'a pas parlé jusqu'à présent,
> c'est que tu as affaire à un système multitâche. Il n'y a pas que ton
> job qui s'exécute et qui doit aller le plus vite possible, il y en a
> d'autres, simultanés, qui lisent d'autres fichiers ailleurs sur le
> disque. Au total le bras va quand même se promener sur le disque et,
> bien sûr, l'OS va intercaler les demandes de lecture et d'écriture des
> différents programmes en fonction de la position de la tête de lecture
> (algorithme de l'ascenseur).
Ça m'étonnerai que ce soit à l'OS de faire cela, primo parce qu'il ne
peut pas savoir où se trouvent les têtes de lecture à un moment donné,
secundo parce que ce n'est pas son rôle. C'est au pire le rôle du
contrôleur SATA, au mieux celui du contrôleur intégré du disque.
Le 16/04/2010 09:53, Michel Talon a écrit :
> En outre un facteur essentiel dont on n'a pas parlé jusqu'à présent,
> c'est que tu as affaire à un système multitâche. Il n'y a pas que ton
> job qui s'exécute et qui doit aller le plus vite possible, il y en a
> d'autres, simultanés, qui lisent d'autres fichiers ailleurs sur le
> disque. Au total le bras va quand même se promener sur le disque et,
> bien sûr, l'OS va intercaler les demandes de lecture et d'écriture des
> différents programmes en fonction de la position de la tête de lecture
> (algorithme de l'ascenseur).
Ça m'étonnerai que ce soit à l'OS de faire cela, primo parce qu'il ne
peut pas savoir où se trouvent les têtes de lecture à un moment donné,
secundo parce que ce n'est pas son rôle. C'est au pire le rôle du
contrôleur SATA, au mieux celui du contrôleur intégré du disque.
Le 16/04/2010 09:53, Michel Talon a écrit :
> En outre un facteur essentiel dont on n'a pas parlé jusqu'à présent,
> c'est que tu as affaire à un système multitâche. Il n'y a pas que ton
> job qui s'exécute et qui doit aller le plus vite possible, il y en a
> d'autres, simultanés, qui lisent d'autres fichiers ailleurs sur le
> disque. Au total le bras va quand même se promener sur le disque et,
> bien sûr, l'OS va intercaler les demandes de lecture et d'écriture des
> différents programmes en fonction de la position de la tête de lecture
> (algorithme de l'ascenseur).
Ça m'étonnerai que ce soit à l'OS de faire cela, primo parce qu'il ne
peut pas savoir où se trouvent les têtes de lecture à un moment donné,
secundo parce que ce n'est pas son rôle. C'est au pire le rôle du
contrôleur SATA, au mieux celui du contrôleur intégré du disque.