Sur un systeme RAID 1 ou RAID 5, il est de bon ton de garder un disque
en "hot spare" sur sa baie, pour le cas malheureux où un disque du
groupe RAID viendrait à lâcher.
Mais quid du "hot spare" sur un RAID 6 ??? En RAID6, on a une redondance
n+2, donc si un disque pète, on est toujours "safe" puisqu'il faut au
moins 2 disques morts pour que ça commence à craindre...
Je me demande donc quelles sont la pratiques fréquemment... pratiquées
par les pros quand ils déploient du RAID6 : hot-spare ou pas hot-spare ?
et si hot-spare, pourquoi ? Par habitude, ou bien y a t'il une vraie
raison technique ?
Le Thu, 15 Apr 2010 21:01:28 +0200, Olivier B. a écrit:
Le taux d'erreur irrécupérable en lecture. C'est à dire qui ne peut être corrigé par les mécanismes de correction du disque.
c'est bien l'erreur signalée par l'interface du disque et générant sur un jbod une erreur coté systeme genre "crc error retry/abort" ?
Oui, par exemple.
Il devrait y avoir une amélioration importante avec les nouveaux disques à blocs de 4K, mais pour l'instant on en est là.
qu'est-ce que la taille du bloc a comme influance ?
Aujourd'hui il y a un CRC de 10 bits pour 512 bits de données. Ce qui fait que l'erreur la plus grande correctible est de 8 bits. Avec les blocs de 4 k dotés d'un CRC de 80 bits, on peut corriger une erreur de 72 bits d'un coup. Donc le taux d'erreur irrécupérable sera pratiqueemnt 9 fois moindre par ce simple effet.
-- If atheism is a religion, then baldness is a hair color. And not collecting stamps is a hobby. mahade on reddit.com
Le Thu, 15 Apr 2010 21:01:28 +0200, Olivier B. a écrit:
Le taux d'erreur irrécupérable en lecture. C'est à dire qui ne peut être
corrigé par les mécanismes de correction du disque.
c'est bien l'erreur signalée par l'interface du disque et générant sur
un jbod une erreur coté systeme genre "crc error retry/abort" ?
Oui, par exemple.
Il devrait y avoir
une amélioration importante avec les nouveaux disques à blocs de 4K,
mais pour l'instant on en est là.
qu'est-ce que la taille du bloc a comme influance ?
Aujourd'hui il y a un CRC de 10 bits pour 512 bits de données. Ce qui
fait que l'erreur la plus grande correctible est de 8 bits. Avec les
blocs de 4 k dotés d'un CRC de 80 bits, on peut corriger une erreur de 72
bits d'un coup. Donc le taux d'erreur irrécupérable sera pratiqueemnt 9
fois moindre par ce simple effet.
--
If atheism is a religion, then baldness is a hair color.
And not collecting stamps is a hobby.
mahade on reddit.com
Le Thu, 15 Apr 2010 21:01:28 +0200, Olivier B. a écrit:
Le taux d'erreur irrécupérable en lecture. C'est à dire qui ne peut être corrigé par les mécanismes de correction du disque.
c'est bien l'erreur signalée par l'interface du disque et générant sur un jbod une erreur coté systeme genre "crc error retry/abort" ?
Oui, par exemple.
Il devrait y avoir une amélioration importante avec les nouveaux disques à blocs de 4K, mais pour l'instant on en est là.
qu'est-ce que la taille du bloc a comme influance ?
Aujourd'hui il y a un CRC de 10 bits pour 512 bits de données. Ce qui fait que l'erreur la plus grande correctible est de 8 bits. Avec les blocs de 4 k dotés d'un CRC de 80 bits, on peut corriger une erreur de 72 bits d'un coup. Donc le taux d'erreur irrécupérable sera pratiqueemnt 9 fois moindre par ce simple effet.
-- If atheism is a religion, then baldness is a hair color. And not collecting stamps is a hobby. mahade on reddit.com
Olivier B.
On 15 Apr 2010 19:54:28 GMT, Emmanuel Florac wrote:
Le Thu, 15 Apr 2010 21:01:28 +0200, Olivier B. a écrit:
Le taux d'erreur irrécupérable en lecture. C'est à dire qui ne peut être corrigé par les mécanismes de correction du disque.
c'est bien l'erreur signalée par l'interface du disque et générant sur un jbod une erreur coté systeme genre "crc error retry/abort" ?
Oui, par exemple.
alors ça le laisse perplexe, j'ai entre autre: 2 grappes de 16 disques 1To en R6 carte areca 1 grappe 8 disques 1To R6/areca 1 grappe 10 disques 2To R6/areca 1 grappe 6 disques 2To R5/soft
si j'en crois les stats que tu donne je devrais avoir eu depuis longtemps des traces de CRC non ?
Il devrait y avoir une amélioration importante avec les nouveaux disques à blocs de 4K, mais pour l'instant on en est là.
qu'est-ce que la taille du bloc a comme influance ?
Aujourd'hui il y a un CRC de 10 bits pour 512 bits de données. Ce qui fait que l'erreur la plus grande correctible est de 8 bits. Avec les blocs de 4 k dotés d'un CRC de 80 bits, on peut corriger une erreur de 72 bits d'un coup. Donc le taux d'erreur irrécupérable sera pratiqueemnt 9 fois moindre par ce simple effet.
ok
-- pas de turlututu. apres l'@robase
On 15 Apr 2010 19:54:28 GMT, Emmanuel Florac <eflorac@imaginet.fr>
wrote:
Le Thu, 15 Apr 2010 21:01:28 +0200, Olivier B. a écrit:
Le taux d'erreur irrécupérable en lecture. C'est à dire qui ne peut être
corrigé par les mécanismes de correction du disque.
c'est bien l'erreur signalée par l'interface du disque et générant sur
un jbod une erreur coté systeme genre "crc error retry/abort" ?
Oui, par exemple.
alors ça le laisse perplexe, j'ai entre autre:
2 grappes de 16 disques 1To en R6 carte areca
1 grappe 8 disques 1To R6/areca
1 grappe 10 disques 2To R6/areca
1 grappe 6 disques 2To R5/soft
si j'en crois les stats que tu donne je devrais avoir eu depuis
longtemps des traces de CRC non ?
Il devrait y avoir
une amélioration importante avec les nouveaux disques à blocs de 4K,
mais pour l'instant on en est là.
qu'est-ce que la taille du bloc a comme influance ?
Aujourd'hui il y a un CRC de 10 bits pour 512 bits de données. Ce qui
fait que l'erreur la plus grande correctible est de 8 bits. Avec les
blocs de 4 k dotés d'un CRC de 80 bits, on peut corriger une erreur de 72
bits d'un coup. Donc le taux d'erreur irrécupérable sera pratiqueemnt 9
fois moindre par ce simple effet.
On 15 Apr 2010 19:54:28 GMT, Emmanuel Florac wrote:
Le Thu, 15 Apr 2010 21:01:28 +0200, Olivier B. a écrit:
Le taux d'erreur irrécupérable en lecture. C'est à dire qui ne peut être corrigé par les mécanismes de correction du disque.
c'est bien l'erreur signalée par l'interface du disque et générant sur un jbod une erreur coté systeme genre "crc error retry/abort" ?
Oui, par exemple.
alors ça le laisse perplexe, j'ai entre autre: 2 grappes de 16 disques 1To en R6 carte areca 1 grappe 8 disques 1To R6/areca 1 grappe 10 disques 2To R6/areca 1 grappe 6 disques 2To R5/soft
si j'en crois les stats que tu donne je devrais avoir eu depuis longtemps des traces de CRC non ?
Il devrait y avoir une amélioration importante avec les nouveaux disques à blocs de 4K, mais pour l'instant on en est là.
qu'est-ce que la taille du bloc a comme influance ?
Aujourd'hui il y a un CRC de 10 bits pour 512 bits de données. Ce qui fait que l'erreur la plus grande correctible est de 8 bits. Avec les blocs de 4 k dotés d'un CRC de 80 bits, on peut corriger une erreur de 72 bits d'un coup. Donc le taux d'erreur irrécupérable sera pratiqueemnt 9 fois moindre par ce simple effet.
ok
-- pas de turlututu. apres l'@robase
Emmanuel Florac
Le Fri, 16 Apr 2010 12:46:20 +0200, Olivier B. a écrit:
si j'en crois les stats que tu donne je devrais avoir eu depuis longtemps des traces de CRC non ?
Non, parce que tant que le RAID est intègre le défaut est masqué.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Fri, 16 Apr 2010 12:46:20 +0200, Olivier B. a écrit:
si j'en crois les stats que tu donne je devrais avoir eu depuis
longtemps des traces de CRC non ?
Non, parce que tant que le RAID est intègre le défaut est masqué.
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
Le Fri, 16 Apr 2010 12:46:20 +0200, Olivier B. a écrit:
si j'en crois les stats que tu donne je devrais avoir eu depuis longtemps des traces de CRC non ?
Non, parce que tant que le RAID est intègre le défaut est masqué.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Olivier B.
On 16 Apr 2010 21:45:06 GMT, Emmanuel Florac wrote:
Le Fri, 16 Apr 2010 12:46:20 +0200, Olivier B. a écrit:
si j'en crois les stats que tu donne je devrais avoir eu depuis longtemps des traces de CRC non ?
Non, parce que tant que le RAID est intègre le défaut est masqué.
???
c'est bien là une chose qui me dérange enormement qu'un raid masque un probleme de disque à l'administrateur ! Le minimum me semble de logguer le crc afin que l'admin puisse corriger le probleme.
A+
-- pas de turlututu. apres l'@robase
On 16 Apr 2010 21:45:06 GMT, Emmanuel Florac <eflorac@imaginet.fr>
wrote:
Le Fri, 16 Apr 2010 12:46:20 +0200, Olivier B. a écrit:
si j'en crois les stats que tu donne je devrais avoir eu depuis
longtemps des traces de CRC non ?
Non, parce que tant que le RAID est intègre le défaut est masqué.
???
c'est bien là une chose qui me dérange enormement qu'un raid masque un
probleme de disque à l'administrateur ! Le minimum me semble de
logguer le crc afin que l'admin puisse corriger le probleme.
On 16 Apr 2010 21:45:06 GMT, Emmanuel Florac wrote:
Le Fri, 16 Apr 2010 12:46:20 +0200, Olivier B. a écrit:
si j'en crois les stats que tu donne je devrais avoir eu depuis longtemps des traces de CRC non ?
Non, parce que tant que le RAID est intègre le défaut est masqué.
???
c'est bien là une chose qui me dérange enormement qu'un raid masque un probleme de disque à l'administrateur ! Le minimum me semble de logguer le crc afin que l'admin puisse corriger le probleme.
A+
-- pas de turlututu. apres l'@robase
Emmanuel Florac
Le Sun, 18 Apr 2010 19:10:07 +0200, Olivier B. a écrit:
c'est bien là une chose qui me dérange enormement qu'un raid masque un probleme de disque à l'administrateur ! Le minimum me semble de logguer le crc afin que l'admin puisse corriger le probleme.
Il n'y a aucun problème à corriger; les disques sont certifiés fonctionner avec un certain taux d'erreur inévitable. Normalement, c'est loggé, il est vrai (CRC error).
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la non-corruption des données, ou alors un FS avec des fonctions de checksum comme ZFS...
-- La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. Anatole France.
Le Sun, 18 Apr 2010 19:10:07 +0200, Olivier B. a écrit:
c'est bien là une chose qui me dérange enormement qu'un raid masque un
probleme de disque à l'administrateur ! Le minimum me semble de logguer
le crc afin que l'admin puisse corriger le probleme.
Il n'y a aucun problème à corriger; les disques sont certifiés
fonctionner avec un certain taux d'erreur inévitable. Normalement, c'est
loggé, il est vrai (CRC error).
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la
non-corruption des données, ou alors un FS avec des fonctions de checksum
comme ZFS...
--
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de
voler du pain.
Anatole France.
Le Sun, 18 Apr 2010 19:10:07 +0200, Olivier B. a écrit:
c'est bien là une chose qui me dérange enormement qu'un raid masque un probleme de disque à l'administrateur ! Le minimum me semble de logguer le crc afin que l'admin puisse corriger le probleme.
Il n'y a aucun problème à corriger; les disques sont certifiés fonctionner avec un certain taux d'erreur inévitable. Normalement, c'est loggé, il est vrai (CRC error).
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la non-corruption des données, ou alors un FS avec des fonctions de checksum comme ZFS...
-- La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. Anatole France.
Olivier B.
On 18 Apr 2010 20:31:19 GMT, Emmanuel Florac wrote:
Le Sun, 18 Apr 2010 19:10:07 +0200, Olivier B. a écrit:
c'est bien là une chose qui me dérange enormement qu'un raid masque un probleme de disque à l'administrateur ! Le minimum me semble de logguer le crc afin que l'admin puisse corriger le probleme.
Il n'y a aucun problème à corriger; les disques sont certifiés fonctionner avec un certain taux d'erreur inévitable. Normalement, c'est loggé, il est vrai (CRC error).
et le systeme (au sens stockage) devrait donc en tenir compte, par exemple readresser le bloc ou refaire une écriture, d'autant qu'il est professionel.
perso tu m'a fichu le cafard, je tremple pour mes fichiers maintenant :-)
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la non-corruption des données, ou alors un FS avec des fonctions de checksum comme ZFS...
je suis en train de créer une base md5 de mes fichiers, des fois que ça serve...
-- pas de turlututu. apres l'@robase
On 18 Apr 2010 20:31:19 GMT, Emmanuel Florac <eflorac@imaginet.fr>
wrote:
Le Sun, 18 Apr 2010 19:10:07 +0200, Olivier B. a écrit:
c'est bien là une chose qui me dérange enormement qu'un raid masque un
probleme de disque à l'administrateur ! Le minimum me semble de logguer
le crc afin que l'admin puisse corriger le probleme.
Il n'y a aucun problème à corriger; les disques sont certifiés
fonctionner avec un certain taux d'erreur inévitable. Normalement, c'est
loggé, il est vrai (CRC error).
et le systeme (au sens stockage) devrait donc en tenir compte, par
exemple readresser le bloc ou refaire une écriture, d'autant qu'il est
professionel.
perso tu m'a fichu le cafard, je tremple pour mes fichiers maintenant
:-)
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la
non-corruption des données, ou alors un FS avec des fonctions de checksum
comme ZFS...
je suis en train de créer une base md5 de mes fichiers, des fois que
ça serve...
On 18 Apr 2010 20:31:19 GMT, Emmanuel Florac wrote:
Le Sun, 18 Apr 2010 19:10:07 +0200, Olivier B. a écrit:
c'est bien là une chose qui me dérange enormement qu'un raid masque un probleme de disque à l'administrateur ! Le minimum me semble de logguer le crc afin que l'admin puisse corriger le probleme.
Il n'y a aucun problème à corriger; les disques sont certifiés fonctionner avec un certain taux d'erreur inévitable. Normalement, c'est loggé, il est vrai (CRC error).
et le systeme (au sens stockage) devrait donc en tenir compte, par exemple readresser le bloc ou refaire une écriture, d'autant qu'il est professionel.
perso tu m'a fichu le cafard, je tremple pour mes fichiers maintenant :-)
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la non-corruption des données, ou alors un FS avec des fonctions de checksum comme ZFS...
je suis en train de créer une base md5 de mes fichiers, des fois que ça serve...
-- pas de turlututu. apres l'@robase
Emmanuel Florac
Le Mon, 19 Apr 2010 21:30:56 +0200, Olivier B. a écrit:
et le systeme (au sens stockage) devrait donc en tenir compte, par exemple readresser le bloc ou refaire une écriture, d'autant qu'il est professionel.
Non, inutile de réadresser le bloc puisque généralement l'erreur est transitoire et passera avec une variation de température ou de vibration.
perso tu m'a fichu le cafard, je tremple pour mes fichiers maintenant
C'est plus justifié déjà :) Ahhh, les maxtor 250 Go et leur corruption galopante :)
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la non-corruption des données, ou alors un FS avec des fonctions de checksum comme ZFS...
je suis en train de créer une base md5 de mes fichiers, des fois que ça serve...
C'est très utile. Personnellement j'utilise un petit démon ( afick ) qui tient une base à jour, ça m'a dépanné une fois ou deux.
-- entia non sont multiplicanda praeter necessitatem. John Ponce of Cork.
Le Mon, 19 Apr 2010 21:30:56 +0200, Olivier B. a écrit:
et le systeme (au sens stockage) devrait donc en tenir compte, par
exemple readresser le bloc ou refaire une écriture, d'autant qu'il est
professionel.
Non, inutile de réadresser le bloc puisque généralement l'erreur est
transitoire et passera avec une variation de température ou de vibration.
perso tu m'a fichu le cafard, je tremple pour mes fichiers maintenant
C'est plus justifié déjà :) Ahhh, les maxtor 250 Go et leur corruption
galopante :)
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la
non-corruption des données, ou alors un FS avec des fonctions de
checksum comme ZFS...
je suis en train de créer une base md5 de mes fichiers, des fois que ça
serve...
C'est très utile. Personnellement j'utilise un petit démon ( afick ) qui
tient une base à jour, ça m'a dépanné une fois ou deux.
--
entia non sont multiplicanda praeter necessitatem.
John Ponce of Cork.
Le Mon, 19 Apr 2010 21:30:56 +0200, Olivier B. a écrit:
et le systeme (au sens stockage) devrait donc en tenir compte, par exemple readresser le bloc ou refaire une écriture, d'autant qu'il est professionel.
Non, inutile de réadresser le bloc puisque généralement l'erreur est transitoire et passera avec une variation de température ou de vibration.
perso tu m'a fichu le cafard, je tremple pour mes fichiers maintenant
C'est plus justifié déjà :) Ahhh, les maxtor 250 Go et leur corruption galopante :)
C'est pourquoi on doit toujours utiliser du RAID si on veut garantir la non-corruption des données, ou alors un FS avec des fonctions de checksum comme ZFS...
je suis en train de créer une base md5 de mes fichiers, des fois que ça serve...
C'est très utile. Personnellement j'utilise un petit démon ( afick ) qui tient une base à jour, ça m'a dépanné une fois ou deux.
-- entia non sont multiplicanda praeter necessitatem. John Ponce of Cork.
