Les disques durs disposent de cache de tailles diverses, avec souvent la
possibilité pour une dizaine d'euros de plus, de passer d'un cache 2MO à
un cache 8MO. La question que je me pose est de savoir si cette dizaine
d'euros est bien employée, autrement dit, si ce cache peut apporter un
réel gain de performances sous Linux...
Je comprend à peu près comment ces caches fonctionnennt et peuvent,
théoriquement apporter un gain de performances, mais ne font-ils pas
double emploi avec le cache du système (souvent bien plus gros), et
l'intelligence déjà incluse dans les systèmes de fichiers (lectures
anticipées, etc...)? Qu'apporte-t-ils de plus, éventuellement?
Par ailleurs, qu'en est-il de la tolérance aux arrêts brutaux, en
particulier avec les systèmes de fichiers journalisés? L'ordre des
écritures sur le disque est-il préservé? Si oui, il me semble que le
cache n'introduit pas réellement de nouveau problème (il ne fait que
décaler les écritures dans le temps). Sinon, le risque d'incohérence
en cas d'arrêt brutal est sérieux.
Commentaires, explications, et retours d'expériences seraient les
bienvenus sur ces questions...
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Pire, certains disques durs (de portables) "oubliaient" leur cache sur un reboot ou même sur mise en veille...
Dommage, c'est justement avec les disques durs de portables (monstrueusement lents) que j'ai constaté les plus gros gains quand on active le cache en écriture.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
On Thu Feb 03 2005 at 15:20, yves wrote:
Pire, certains disques durs (de portables) "oubliaient"
leur cache sur un reboot ou même sur mise en veille...
Dommage, c'est justement avec les disques durs de portables
(monstrueusement lents) que j'ai constaté les plus gros gains quand on
active le cache en écriture.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Pire, certains disques durs (de portables) "oubliaient" leur cache sur un reboot ou même sur mise en veille...
Dommage, c'est justement avec les disques durs de portables (monstrueusement lents) que j'ai constaté les plus gros gains quand on active le cache en écriture.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Michel Arboi
On Wed Feb 02 2005 at 23:19, Dominique ROUSSEAU wrote:
Mais ce n'est pas pour ça que ça n'arrivera jamais. Le tout est pour chacun d'évaluer le risque qu'il peut/veut prendre.
Je n'ai jamais eu de problème avec le cache et je ne connais personne qui en ait eu alors que j'ai déjà perdu des données sur des casses matérielles.
Par forcément. Si ils "profitent" de la présence de la tête de lecture/écriture à proximité d'une zone où une opération d'écriture doit être effectuée, l'ordre peut ne pas être repsecté, aboutissant à des données incohérentes si la totalité des données du journal n'est pas écrite.
C'est certainement plus difficile à coder. Pourquoi les constructeurs de disques feraient des efforts pour se tirer dans le pied ?
Tu as une source pour cette info ?
Non, et Google est muet. C'est peut-être une légende...
Quand on a des données auxquelles on tient vraiment, si.
Quand on a de telles données, on mirrore, on fait des sauvegardes, mais on ne fait pas confiance à la quincaillerie :-)
Je ne suis pas spécialisé en gestion de cache disque, mais j'imagine que le genre de gains apportés par les caches multiniveau sur les microprocesseurs doit pouvoir se retrouver plus ou moins dans le fonctionnement des disques durs, non ?
Les caches L1, L2 et L3 des procs sont gérés différemment et se complètent. Je ne suis pas convaincu qu'on puisse inventer des choses très originales pour "cacher" un disque.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
On Wed Feb 02 2005 at 23:19, Dominique ROUSSEAU wrote:
Mais ce n'est pas pour ça que ça n'arrivera jamais.
Le tout est pour chacun d'évaluer le risque qu'il peut/veut prendre.
Je n'ai jamais eu de problème avec le cache et je ne connais personne
qui en ait eu alors que j'ai déjà perdu des données sur des casses
matérielles.
Par forcément. Si ils "profitent" de la présence de la tête de
lecture/écriture à proximité d'une zone où une opération d'écriture doit
être effectuée, l'ordre peut ne pas être repsecté, aboutissant à des
données incohérentes si la totalité des données du journal n'est pas
écrite.
C'est certainement plus difficile à coder. Pourquoi les constructeurs
de disques feraient des efforts pour se tirer dans le pied ?
Tu as une source pour cette info ?
Non, et Google est muet. C'est peut-être une légende...
Quand on a des données auxquelles on tient vraiment, si.
Quand on a de telles données, on mirrore, on fait des sauvegardes,
mais on ne fait pas confiance à la quincaillerie :-)
Je ne suis pas spécialisé en gestion de cache disque, mais j'imagine que
le genre de gains apportés par les caches multiniveau sur les
microprocesseurs doit pouvoir se retrouver plus ou moins dans le
fonctionnement des disques durs, non ?
Les caches L1, L2 et L3 des procs sont gérés différemment et se
complètent. Je ne suis pas convaincu qu'on puisse inventer des choses
très originales pour "cacher" un disque.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
On Wed Feb 02 2005 at 23:19, Dominique ROUSSEAU wrote:
Mais ce n'est pas pour ça que ça n'arrivera jamais. Le tout est pour chacun d'évaluer le risque qu'il peut/veut prendre.
Je n'ai jamais eu de problème avec le cache et je ne connais personne qui en ait eu alors que j'ai déjà perdu des données sur des casses matérielles.
Par forcément. Si ils "profitent" de la présence de la tête de lecture/écriture à proximité d'une zone où une opération d'écriture doit être effectuée, l'ordre peut ne pas être repsecté, aboutissant à des données incohérentes si la totalité des données du journal n'est pas écrite.
C'est certainement plus difficile à coder. Pourquoi les constructeurs de disques feraient des efforts pour se tirer dans le pied ?
Tu as une source pour cette info ?
Non, et Google est muet. C'est peut-être une légende...
Quand on a des données auxquelles on tient vraiment, si.
Quand on a de telles données, on mirrore, on fait des sauvegardes, mais on ne fait pas confiance à la quincaillerie :-)
Je ne suis pas spécialisé en gestion de cache disque, mais j'imagine que le genre de gains apportés par les caches multiniveau sur les microprocesseurs doit pouvoir se retrouver plus ou moins dans le fonctionnement des disques durs, non ?
Les caches L1, L2 et L3 des procs sont gérés différemment et se complètent. Je ne suis pas convaincu qu'on puisse inventer des choses très originales pour "cacher" un disque.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
yves
Michel Arboi a écrit :
On Wed Feb 02 2005 at 23:19, Dominique ROUSSEAU wrote:
Mais ce n'est pas pour ça que ça n'arrivera jamais. Le tout est pour chacun d'évaluer le risque qu'il peut/veut prendre.
Je n'ai jamais eu de problème avec le cache et je ne connais personne qui en ait eu alors que j'ai déjà perdu des données sur des casses matérielles.
Ma première recherche sur le sujet (il y a quelques années) avait été faite suite justement à des connaissances ayant des corruptions du fs assez importantes... Mais pas de nouvelles depuis cette époque. Alors, désactivation du write cache par défaut sous linux, ou améliorations de la part des constructeurs ?
-- http://wiki.rougy.net -- Wiki Unix/Linux
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Michel Arboi a écrit :
On Wed Feb 02 2005 at 23:19, Dominique ROUSSEAU wrote:
Mais ce n'est pas pour ça que ça n'arrivera jamais.
Le tout est pour chacun d'évaluer le risque qu'il peut/veut prendre.
Je n'ai jamais eu de problème avec le cache et je ne connais personne
qui en ait eu alors que j'ai déjà perdu des données sur des casses
matérielles.
Ma première recherche sur le sujet (il y a quelques années) avait été
faite suite justement à des connaissances ayant des corruptions du fs
assez importantes... Mais pas de nouvelles depuis cette époque. Alors,
désactivation du write cache par défaut sous linux, ou améliorations de
la part des constructeurs ?
--
http://wiki.rougy.net -- Wiki Unix/Linux
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
On Wed Feb 02 2005 at 23:19, Dominique ROUSSEAU wrote:
Mais ce n'est pas pour ça que ça n'arrivera jamais. Le tout est pour chacun d'évaluer le risque qu'il peut/veut prendre.
Je n'ai jamais eu de problème avec le cache et je ne connais personne qui en ait eu alors que j'ai déjà perdu des données sur des casses matérielles.
Ma première recherche sur le sujet (il y a quelques années) avait été faite suite justement à des connaissances ayant des corruptions du fs assez importantes... Mais pas de nouvelles depuis cette époque. Alors, désactivation du write cache par défaut sous linux, ou améliorations de la part des constructeurs ?
-- http://wiki.rougy.net -- Wiki Unix/Linux
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Gilles Berger Sabbatel
On Sun, 06 Feb 2005 19:56:26 +0000, Michel Arboi wrote:
Par forcément. Si ils "profitent" de la présence de la tête de lecture/écriture à proximité d'une zone où une opération d'écriture doit être effectuée, l'ordre peut ne pas être repsecté, aboutissant à des données incohérentes si la totalité des données du journal n'est pas écrite.
C'est certainement plus difficile à coder. Pourquoi les constructeurs de disques feraient des efforts pour se tirer dans le pied ?
On sait depuis les années 70 que la façon optimale de traiter les accès disques en attente consiste à les prendre dans l'ordre des cylindres (ascendant ou descendant, on change de sens quand on arrive au bout) : ça s'appelle la stratégie de l'ascenseur. Je ne sais pas si Linux fait cela, mais s'il le fait, un réordonnancement effectué par le disque n'apportera rien ou presque. Et s'il ne le fait pas, c'est qu'il y a sûrement une bonne raison : gain marginal qui ne justifie pas la complexité, problèmes de cohérence...
De toutes façons, il faut être réalistes : les disques sont conçus pour Windows, pas pour Linux! Et ce qui est de peu d'intérêt (voire dangereux) sous Linux peut très bien apporter un réel gain de performances sous Windows (qui n'a pas besoin de cache disque pour être dangereux, de toutes façons :-) ).
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
On Sun, 06 Feb 2005 19:56:26 +0000, Michel Arboi wrote:
Par forcément. Si ils "profitent" de la présence de la tête de
lecture/écriture à proximité d'une zone où une opération
d'écriture doit être effectuée, l'ordre peut ne pas être repsecté,
aboutissant à des données incohérentes si la totalité des données
du journal n'est pas écrite.
C'est certainement plus difficile à coder. Pourquoi les constructeurs de
disques feraient des efforts pour se tirer dans le pied ?
On sait depuis les années 70 que la façon optimale de traiter les accès
disques en attente consiste à les prendre dans l'ordre des cylindres
(ascendant ou descendant, on change de sens quand on arrive au bout) : ça
s'appelle la stratégie de l'ascenseur. Je ne sais pas si Linux fait
cela, mais s'il le fait, un réordonnancement effectué par le disque
n'apportera rien ou presque. Et s'il ne le fait pas, c'est qu'il y a
sûrement une bonne raison : gain marginal qui ne justifie pas la
complexité, problèmes de cohérence...
De toutes façons, il faut être réalistes : les disques sont conçus
pour Windows, pas pour Linux! Et ce qui est de peu d'intérêt (voire
dangereux) sous Linux peut très bien apporter un réel gain de
performances sous Windows (qui n'a pas besoin de cache disque pour être
dangereux, de toutes façons :-) ).
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
On Sun, 06 Feb 2005 19:56:26 +0000, Michel Arboi wrote:
Par forcément. Si ils "profitent" de la présence de la tête de lecture/écriture à proximité d'une zone où une opération d'écriture doit être effectuée, l'ordre peut ne pas être repsecté, aboutissant à des données incohérentes si la totalité des données du journal n'est pas écrite.
C'est certainement plus difficile à coder. Pourquoi les constructeurs de disques feraient des efforts pour se tirer dans le pied ?
On sait depuis les années 70 que la façon optimale de traiter les accès disques en attente consiste à les prendre dans l'ordre des cylindres (ascendant ou descendant, on change de sens quand on arrive au bout) : ça s'appelle la stratégie de l'ascenseur. Je ne sais pas si Linux fait cela, mais s'il le fait, un réordonnancement effectué par le disque n'apportera rien ou presque. Et s'il ne le fait pas, c'est qu'il y a sûrement une bonne raison : gain marginal qui ne justifie pas la complexité, problèmes de cohérence...
De toutes façons, il faut être réalistes : les disques sont conçus pour Windows, pas pour Linux! Et ce qui est de peu d'intérêt (voire dangereux) sous Linux peut très bien apporter un réel gain de performances sous Windows (qui n'a pas besoin de cache disque pour être dangereux, de toutes façons :-) ).
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
