j'ai entendu parler d'une configuration dans laquelle on a une
combinaison entre un HDD ordinaire pour l'espace, et un SSD pour la
rapidité
dans cette configuration, le SSD n'aurais pas un rÍ´le de disque séparé
mais de "tampon" ou de "cache" (je ne sais pas tjr quel est le mot le
plus approprié)
j'ai cru comprendre que c'était possible de l'avoir avec un ordi de ce
type :
https://www.ldlc.com/fiche/PB00260502.html
donc que la combinaison entre le HDD et le SSD n'est pas obligatoirement
gérée par le matériel
mais si on installe un OS sans rien indiquer de particulier, il va fort
logiquement considérer qu'il a simplement 2 disques différents Í sa
disposition, et il va simplement nous demander sur lequel on veut
installer l'OS
donc la question, c'est simplement :
est ce que c'est dur Í parametrer, ce que je veux ?
pour l'instant, je n'ai jamais fait autre chose que l'installation
standard dans virtualbox
question subsidiaire : est ce que c'est possible de faire la même chose
avec un SSD interne et un HDD externe usb ?
en second choix, j'ai entendu dire qu'on peut installer le système sur
le SSD et les données utilisateur sur le HDD :
même question : est ce que c'est dur Í faire ?
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Mais encore ?
Nicolas George
pehache , dans le message , a écrit :
Mais encore ?
Aussi fréquents que tu les fasses, des backups ne seront jamais aussi fréquents que la synchronisation d'un RAID1, donc un RAID1 réduit aussi le risque de perte de données en cas de panne. Et ce n'est qu'un exemple trouvé en quelques secondes. Plus généralement, si tu affirmes «Â machin ne sert qu'Í truc », tu dois prouver l'unicité, donc tu dois prouver que machin ne peut servir Í absolument rien d'autre que truc. Tu vas avoir du mal. Donc il vaut mieux s'abstenir de ce genre d'affirmation universelles.
pehache , dans le message <hvm12hzK-oNn0wzITMxFfcrjo_I@jntp>, a écrit :
Mais encore ?
Aussi fréquents que tu les fasses, des backups ne seront jamais aussi
fréquents que la synchronisation d'un RAID1, donc un RAID1 réduit aussi le
risque de perte de données en cas de panne.
Et ce n'est qu'un exemple trouvé en quelques secondes.
Plus généralement, si tu affirmes «Â machin ne sert qu'Í truc », tu dois
prouver l'unicité, donc tu dois prouver que machin ne peut servir Í
absolument rien d'autre que truc. Tu vas avoir du mal. Donc il vaut mieux
s'abstenir de ce genre d'affirmation universelles.
Aussi fréquents que tu les fasses, des backups ne seront jamais aussi fréquents que la synchronisation d'un RAID1, donc un RAID1 réduit aussi le risque de perte de données en cas de panne. Et ce n'est qu'un exemple trouvé en quelques secondes. Plus généralement, si tu affirmes «Â machin ne sert qu'Í truc », tu dois prouver l'unicité, donc tu dois prouver que machin ne peut servir Í absolument rien d'autre que truc. Tu vas avoir du mal. Donc il vaut mieux s'abstenir de ce genre d'affirmation universelles.
Yliur
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ? Et dans ce cas, combien peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message <i99gbhFqrifU1@mid.individual.net>, a écrit :
Le RAID 1 c'est fait pour maintenir la
disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on
peut paralléliser les lectures sur les deux disques. Est-ce utilisé
uniquement quand il y a des accès disques simultanés par plusieurs
programmes, ou bien également pour une lecture séquentielle (ou non) de
fichiers par un seul programme (le système réclamant des données aux deux
disques, par exemple en alternant les blocs) ? Et dans ce cas, combien
peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ? Et dans ce cas, combien peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
pehache
Le 19/02/2021 Í 16:30, Nicolas George a écrit :
pehache , dans le message , a écrit :
Mais encore ?
Aussi fréquents que tu les fasses, des backups ne seront jamais aussi fréquents que la synchronisation d'un RAID1, donc un RAID1 réduit aussi le risque de perte de données en cas de panne.
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense que les contextes o͹ on ne peut pas se permettre de perdre la moindre donnée récente sont aussi ceux o͹ il y a besoin d'une haute disponibilité, donc les deux besoins se mélangent en général. J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et pas le second.
Le 19/02/2021 Í 16:30, Nicolas George a écrit :
pehache , dans le message <hvm12hzK-oNn0wzITMxFfcrjo_I@jntp>, a écrit :
Mais encore ?
Aussi fréquents que tu les fasses, des backups ne seront jamais aussi
fréquents que la synchronisation d'un RAID1, donc un RAID1 réduit aussi le
risque de perte de données en cas de panne.
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense
que les contextes o͹ on ne peut pas se permettre de perdre la moindre
donnée récente sont aussi ceux o͹ il y a besoin d'une haute
disponibilité, donc les deux besoins se mélangent en général.
J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et
pas le second.
Aussi fréquents que tu les fasses, des backups ne seront jamais aussi fréquents que la synchronisation d'un RAID1, donc un RAID1 réduit aussi le risque de perte de données en cas de panne.
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense que les contextes o͹ on ne peut pas se permettre de perdre la moindre donnée récente sont aussi ceux o͹ il y a besoin d'une haute disponibilité, donc les deux besoins se mélangent en général. J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et pas le second.
Nicolas George
pehache , dans le message , a écrit :
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense que les contextes o͹ on ne peut pas se permettre de perdre la moindre
Ce n'est pas une question de ne pas se permettre. Il faut arrêter avec l'absolutisme. Si une technologie divise les risques de pertes de données par dix, c'est bon Í prendre, même quand on peut se permettre de les perdre.
donnée récente sont aussi ceux o͹ il y a besoin d'une haute disponibilité, donc les deux besoins se mélangent en général. J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et pas le second.
Pourtant, il ne faut pas réfléchir bien longtemps. Tu préfères quoi : «Â Serveur en rade, revenez demain. » «Â Les données des dix dernières minutes ont été perdues. Si vous avez payer quelque chose pendant le temps, dommage. » D'une manière générale, il y a peu de choses qui sont plus graves qu'une perte de données.
pehache , dans le message <i9a6k9FlmtU1@mid.individual.net>, a écrit :
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense
que les contextes o͹ on ne peut pas se permettre de perdre la moindre
Ce n'est pas une question de ne pas se permettre. Il faut arrêter avec
l'absolutisme. Si une technologie divise les risques de pertes de données
par dix, c'est bon Í prendre, même quand on peut se permettre de les perdre.
donnée récente sont aussi ceux o͹ il y a besoin d'une haute
disponibilité, donc les deux besoins se mélangent en général.
J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et
pas le second.
Pourtant, il ne faut pas réfléchir bien longtemps. Tu préfères quoi :
«Â Serveur en rade, revenez demain. »
«Â Les données des dix dernières minutes ont été perdues. Si vous avez payer
quelque chose pendant le temps, dommage. »
D'une manière générale, il y a peu de choses qui sont plus graves qu'une
perte de données.
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense que les contextes o͹ on ne peut pas se permettre de perdre la moindre
Ce n'est pas une question de ne pas se permettre. Il faut arrêter avec l'absolutisme. Si une technologie divise les risques de pertes de données par dix, c'est bon Í prendre, même quand on peut se permettre de les perdre.
donnée récente sont aussi ceux o͹ il y a besoin d'une haute disponibilité, donc les deux besoins se mélangent en général. J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et pas le second.
Pourtant, il ne faut pas réfléchir bien longtemps. Tu préfères quoi : «Â Serveur en rade, revenez demain. » «Â Les données des dix dernières minutes ont été perdues. Si vous avez payer quelque chose pendant le temps, dommage. » D'une manière générale, il y a peu de choses qui sont plus graves qu'une perte de données.
pehache
Le 19/02/2021 Í 16:48, Yliur a écrit :
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ? Et dans ce cas, combien peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
En théorie ça pourrait, mais en pratique j'ai des doutes (en tous cas avec les HDD, soumis aux temps d'accès mécaniques). Ca doit dépendre pas mal du contrÍ´leur RAID.
Le 19/02/2021 Í 16:48, Yliur a écrit :
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message <i99gbhFqrifU1@mid.individual.net>, a écrit :
Le RAID 1 c'est fait pour maintenir la
disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on
peut paralléliser les lectures sur les deux disques. Est-ce utilisé
uniquement quand il y a des accès disques simultanés par plusieurs
programmes, ou bien également pour une lecture séquentielle (ou non) de
fichiers par un seul programme (le système réclamant des données aux deux
disques, par exemple en alternant les blocs) ? Et dans ce cas, combien
peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
En théorie ça pourrait, mais en pratique j'ai des doutes (en tous cas
avec les HDD, soumis aux temps d'accès mécaniques). Ca doit dépendre pas
mal du contrÍ´leur RAID.
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ? Et dans ce cas, combien peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
En théorie ça pourrait, mais en pratique j'ai des doutes (en tous cas avec les HDD, soumis aux temps d'accès mécaniques). Ca doit dépendre pas mal du contrÍ´leur RAID.
Yliur
Le Fri, 19 Feb 2021 17:39:18 +0100, pehache a écrit :
Le 19/02/2021 Í 16:48, Yliur a écrit :
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ? Et dans ce cas, combien peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
En théorie ça pourrait, mais en pratique j'ai des doutes (en tous cas avec les HDD, soumis aux temps d'accès mécaniques). Ca doit dépendre pas mal du contrÍ´leur RAID.
Je pensais plutÍ´t au RAID logiciel de linux. Si je comprends bien, Í la base c'est surtout utile quand plusieurs processus accèdent aux disques. Je comprends que pour un disque mécanique ce n'est pas très utile pour lire un seul fichier, puisque de toutes façon on attend la rotation du disque : ça ne sert Í rien d'en lire deux en même temps. Par contre pour des disques électroniques (SSD), ça ne vaut pas le coup de lancer la lecture de blocs alternés, quand le deuxième disque n'a rien de mieux Í faire ? Ce travail sur btrfs est très récent semble-t-il : https://lkml.org/lkml/2021/2/9/1049 Est-ce que ça dit qu'avec la politique roundrobin les résultats sont effectivement meilleurs, y compris pour une lecture d'un seul fichier ? Je ne comprends pas bien les résultats des tests qu'il réalise, il y a beaucoup de chiffres par ligne de résultat. Il n'y a pas non plus de tests avec seulement des SSD.
Le Fri, 19 Feb 2021 17:39:18 +0100, pehache a écrit :
Le 19/02/2021 Í 16:48, Yliur a écrit :
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message <i99gbhFqrifU1@mid.individual.net>, a
écrit :
Le RAID 1 c'est fait pour maintenir la
disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on
peut paralléliser les lectures sur les deux disques. Est-ce utilisé
uniquement quand il y a des accès disques simultanés par plusieurs
programmes, ou bien également pour une lecture séquentielle (ou non) de
fichiers par un seul programme (le système réclamant des données aux
deux disques, par exemple en alternant les blocs) ? Et dans ce cas,
combien peut-on espérer gagner en débit de lecture, est-ce que ça peut
doubler ?
En théorie ça pourrait, mais en pratique j'ai des doutes (en tous cas
avec les HDD, soumis aux temps d'accès mécaniques). Ca doit dépendre pas
mal du contrÍ´leur RAID.
Je pensais plutÍ´t au RAID logiciel de linux. Si je comprends bien, Í la
base c'est surtout utile quand plusieurs processus accèdent aux disques.
Je comprends que pour un disque mécanique ce n'est pas très utile pour
lire un seul fichier, puisque de toutes façon on attend la rotation du
disque : ça ne sert Í rien d'en lire deux en même temps.
Par contre pour des disques électroniques (SSD), ça ne vaut pas le coup
de lancer la lecture de blocs alternés, quand le deuxième disque n'a rien
de mieux Í faire ?
Ce travail sur btrfs est très récent semble-t-il :
https://lkml.org/lkml/2021/2/9/1049
Est-ce que ça dit qu'avec la politique roundrobin les résultats sont
effectivement meilleurs, y compris pour une lecture d'un seul fichier ?
Je ne comprends pas bien les résultats des tests qu'il réalise, il y a
beaucoup de chiffres par ligne de résultat.
Il n'y a pas non plus de tests avec seulement des SSD.
Le Fri, 19 Feb 2021 17:39:18 +0100, pehache a écrit :
Le 19/02/2021 Í 16:48, Yliur a écrit :
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ? Et dans ce cas, combien peut-on espérer gagner en débit de lecture, est-ce que ça peut doubler ?
En théorie ça pourrait, mais en pratique j'ai des doutes (en tous cas avec les HDD, soumis aux temps d'accès mécaniques). Ca doit dépendre pas mal du contrÍ´leur RAID.
Je pensais plutÍ´t au RAID logiciel de linux. Si je comprends bien, Í la base c'est surtout utile quand plusieurs processus accèdent aux disques. Je comprends que pour un disque mécanique ce n'est pas très utile pour lire un seul fichier, puisque de toutes façon on attend la rotation du disque : ça ne sert Í rien d'en lire deux en même temps. Par contre pour des disques électroniques (SSD), ça ne vaut pas le coup de lancer la lecture de blocs alternés, quand le deuxième disque n'a rien de mieux Í faire ? Ce travail sur btrfs est très récent semble-t-il : https://lkml.org/lkml/2021/2/9/1049 Est-ce que ça dit qu'avec la politique roundrobin les résultats sont effectivement meilleurs, y compris pour une lecture d'un seul fichier ? Je ne comprends pas bien les résultats des tests qu'il réalise, il y a beaucoup de chiffres par ligne de résultat. Il n'y a pas non plus de tests avec seulement des SSD.
Pascal Hambourg
Le 19/02/2021 Í 10:45, yamo' a écrit :
par contre est-ce une bonne idée de faire un raid avec un disque rapide et un disque lent?
Ça dépend du type de RAID. Avec du RAID 0 ou 10, le disque lent va tirer les performances vers le bas. Avec du RAID 1, la vitesse en écriture est celle du disque lent mais la vitesse de lecture peut être celle du disque rapide si le RAID lit préférentiellement sur ce dernier (ce que le RAID logiciel de Linux sait faire, cf. option --write-mostly).
Le 19/02/2021 Í 10:45, yamo' a écrit :
par contre est-ce une bonne idée de faire un raid avec un disque rapide
et un disque lent?
Ça dépend du type de RAID. Avec du RAID 0 ou 10, le disque lent va tirer
les performances vers le bas. Avec du RAID 1, la vitesse en écriture est
celle du disque lent mais la vitesse de lecture peut être celle du
disque rapide si le RAID lit préférentiellement sur ce dernier (ce que
le RAID logiciel de Linux sait faire, cf. option --write-mostly).
par contre est-ce une bonne idée de faire un raid avec un disque rapide et un disque lent?
Ça dépend du type de RAID. Avec du RAID 0 ou 10, le disque lent va tirer les performances vers le bas. Avec du RAID 1, la vitesse en écriture est celle du disque lent mais la vitesse de lecture peut être celle du disque rapide si le RAID lit préférentiellement sur ce dernier (ce que le RAID logiciel de Linux sait faire, cf. option --write-mostly).
Pascal Hambourg
Le 19/02/2021 Í 16:48, Yliur a écrit :
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ?
Le RAID 1 ne peut pas améliorer la vitesse de lecture séquentielle. Pour cela, il faut du striping (RAID 0, 5, 6, 10). En revanche il peut améliorer la vitesse de lecture aléatoire ou lors d'accès concurrents.
Le 19/02/2021 Í 16:48, Yliur a écrit :
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message <i99gbhFqrifU1@mid.individual.net>, a écrit :
Le RAID 1 c'est fait pour maintenir la
disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on
peut paralléliser les lectures sur les deux disques. Est-ce utilisé
uniquement quand il y a des accès disques simultanés par plusieurs
programmes, ou bien également pour une lecture séquentielle (ou non) de
fichiers par un seul programme (le système réclamant des données aux deux
disques, par exemple en alternant les blocs) ?
Le RAID 1 ne peut pas améliorer la vitesse de lecture séquentielle. Pour
cela, il faut du striping (RAID 0, 5, 6, 10). En revanche il peut
améliorer la vitesse de lecture aléatoire ou lors d'accès concurrents.
Le Fri, 19 Feb 2021 13:37:40 +0000, Nicolas George a écrit :
pehache , dans le message , a écrit :
Le RAID 1 c'est fait pour maintenir la disponibilité en cas de panne d'un disque
Pas seulement.
Il me semble que c'est censé augmenter la vitesse de lecture, puisqu'on peut paralléliser les lectures sur les deux disques. Est-ce utilisé uniquement quand il y a des accès disques simultanés par plusieurs programmes, ou bien également pour une lecture séquentielle (ou non) de fichiers par un seul programme (le système réclamant des données aux deux disques, par exemple en alternant les blocs) ?
Le RAID 1 ne peut pas améliorer la vitesse de lecture séquentielle. Pour cela, il faut du striping (RAID 0, 5, 6, 10). En revanche il peut améliorer la vitesse de lecture aléatoire ou lors d'accès concurrents.
pehache
Le 19/02/2021 Í 17:22, Nicolas George a écrit :
pehache , dans le message , a écrit :
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense que les contextes o͹ on ne peut pas se permettre de perdre la moindre
Ce n'est pas une question de ne pas se permettre. Il faut arrêter avec l'absolutisme. Si une technologie divise les risques de pertes de données par dix, c'est bon Í prendre, même quand on peut se permettre de les perdre.
Façon de parler, hein...
donnée récente sont aussi ceux o͹ il y a besoin d'une haute disponibilité, donc les deux besoins se mélangent en général. J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et pas le second.
Pourtant, il ne faut pas réfléchir bien longtemps. Tu préfères quoi : «Â Serveur en rade, revenez demain. » «Â Les données des dix dernières minutes ont été perdues. Si vous avez payer quelque chose pendant le temps, dommage. » D'une manière générale, il y a peu de choses qui sont plus graves qu'une perte de données.
Tu aussi tu donnes dans l'absolutisme. Une perte de données tu peux la traduire par le coÍ»t nécessaire pour les régénérer (ou pour compenser les dégÍ¢ts si pas régénérables). De même pour une indisponibilité. J'ai le sentiment que le coÍ»t de "Serveur en rade, revenez demain" n'a pas de raison d'être inférieur au coÍ»t de "Les données des dix dernières minutes ont été perdues".
Le 19/02/2021 Í 17:22, Nicolas George a écrit :
pehache , dans le message <i9a6k9FlmtU1@mid.individual.net>, a écrit :
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense
que les contextes o͹ on ne peut pas se permettre de perdre la moindre
Ce n'est pas une question de ne pas se permettre. Il faut arrêter avec
l'absolutisme. Si une technologie divise les risques de pertes de données
par dix, c'est bon Í prendre, même quand on peut se permettre de les perdre.
Façon de parler, hein...
donnée récente sont aussi ceux o͹ il y a besoin d'une haute
disponibilité, donc les deux besoins se mélangent en général.
J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et
pas le second.
Pourtant, il ne faut pas réfléchir bien longtemps. Tu préfères quoi :
«Â Serveur en rade, revenez demain. »
«Â Les données des dix dernières minutes ont été perdues. Si vous avez payer
quelque chose pendant le temps, dommage. »
D'une manière générale, il y a peu de choses qui sont plus graves qu'une
perte de données.
Tu aussi tu donnes dans l'absolutisme. Une perte de données tu peux la
traduire par le coÍ»t nécessaire pour les régénérer (ou pour compenser
les dégÍ¢ts si pas régénérables). De même pour une indisponibilité. J'ai
le sentiment que le coͻt de "Serveur en rade, revenez demain" n'a pas de
raison d'être inférieur au coÍ»t de "Les données des dix dernières
minutes ont été perdues".
Formellement c'est vrai (et je n'avais pas pensé Í ça). Mais je pense que les contextes o͹ on ne peut pas se permettre de perdre la moindre
Ce n'est pas une question de ne pas se permettre. Il faut arrêter avec l'absolutisme. Si une technologie divise les risques de pertes de données par dix, c'est bon Í prendre, même quand on peut se permettre de les perdre.
Façon de parler, hein...
donnée récente sont aussi ceux o͹ il y a besoin d'une haute disponibilité, donc les deux besoins se mélangent en général. J'ai du mal Í envisager un cas o͹ le premier besoin serait évident et pas le second.
Pourtant, il ne faut pas réfléchir bien longtemps. Tu préfères quoi : «Â Serveur en rade, revenez demain. » «Â Les données des dix dernières minutes ont été perdues. Si vous avez payer quelque chose pendant le temps, dommage. » D'une manière générale, il y a peu de choses qui sont plus graves qu'une perte de données.
Tu aussi tu donnes dans l'absolutisme. Une perte de données tu peux la traduire par le coÍ»t nécessaire pour les régénérer (ou pour compenser les dégÍ¢ts si pas régénérables). De même pour une indisponibilité. J'ai le sentiment que le coÍ»t de "Serveur en rade, revenez demain" n'a pas de raison d'être inférieur au coÍ»t de "Les données des dix dernières minutes ont été perdues".
