FUUUUUUUUUUU UUUUUUUUUU UUUUUUUUUUU UUUUUUUUUUUUU - Page 94

Le processus "imprimer, signer, scanner" est plutôt standard, c'est utilisé aussi par les journaux scientifiques par exemple. Une signature papier a une valeur légale.

A propos des NAS, j'avais conseillé à mon frère de mettre sur un cloud backblaze (5E par To par mois) tout son nas et pas juste ses projets terminés. Il n'avait pas voulu. Aujourd'hui, pour une raison indéterminée, son qnap en raid 6 à déconnecté 2 disques. Le raid a donc continué de fonctionner, et quand il a redémarré son nas il en a pour 10 heure pour faire une synchro complète. Donc là ça va être le stress toute la nuit pour pas qu'un disque pète dans le process.
C'est vraiment con car s'il doit amener son nas à une boîte de récupération de données ça va coûter une fortune.

Arvi89 (./2792) :
ça va être le stress toute la nuit pour pas qu'un disque pète dans le process.

Oui enfin ça serait vraiment pas de chance tout de même, non ?

Oui, ils n'ont qu'un an et pas aucun problème, mais on sait jamais.

C'est sûr ^^

Pen^2 (./2793) :
Oui enfin ça serait vraiment pas de chance tout de même, non ?

Malheureusement, si tes disques sont tous de la même série, et qu'ils ont été utilisés dans des conditions identiques (ce qui est le cas pour du RAID), la proba que les pannes soient rapprochées dans le temps augmente pas mal. En plus la reconstruction est une opération intensive, qui peut faire basculer un disque de l'état "fonctionnel mais marginal" à "en panne". En pratique il y a un certain nombre de personnes qui se sont faites avoir comme ça.

C'est pour ça qu'il vaut mieux utiliser des disques de modèles (voire de fabricants) différents, si on peut.

, j'en suis bien conscient
Si j'avais plusieurs disques c'est ce que je ferais aussi ^^

Pen^2 (./2793) :

Arvi89 (./2792) :
ça va être le stress toute la nuit pour pas qu'un disque pète dans le process.

Oui enfin ça serait vraiment pas de chance tout de même, non ?

J'ai fait le calcul pour le boulot (au moment de choisir RAID5 / RAID6), et ça dépend pas mal des modèles de disques.

J'ai lu plusieurs fois qu'on a un taux d'échec de 10^-14/bit sur un disque standard.
En admettant que tu aies 4 disques de 4 To à lire, et qu'un bit suffise à faire foirer la reconstruction (de mémoire, c'est le cas avec du RAID).
4 To donne 32 Tb, donc 32 * 10^12.
La probabilité de réussite est donc pour lire un seul disque de (1-10^-14)^(4 * 32 * 10^12), soit 72%.
Ça monte à 95% avec des disques NAS à 10^-15 erreur/bit.

Vu qu'il est nécessaire de lire les 4 disques sans erreur, ça donne respectivement 27 et 88%.

À nouveau, c'est en admettant les probabilités (certainement pessimistes) sur les disques.

Mais là les 2 disques qui ont été déconnecté n'ont pas de soucis, on ne sait pas pourquoi le nas les a enlevé. Donc on espère que ça ira.

flan : dans ce cas, ça vaut le coup d'utiliser un système de fichiers comme ZFS qui peut détecter ce genre de problèmes.

Mais pas les corriger

Quand ils donnent le taux d'échec, je ne sais pas si ce sont des erreurs persistantes ou des erreurs transitoires. Dans le second cas, simplement relire les données devrait suffire.

Oui, quand ton RAID (ou équivalent) est encore fonctionnel, mais encore faut-il que la détection puisse avoir lieu (je ne sais pas à quelle fréquence l'intégralité de ton disque est vérifiée).

Zerosquare (./2802) :
Quand ils donnent le taux d'échec, je ne sais pas si ce sont des erreurs persistantes ou des erreurs transitoires. Dans le second cas, simplement relire les données devrait suffire.

Aucune idée Et je n'ai pas eu d'échec de reconstruction de RAID pour faire des tests approfondis

le mec a vraiment du faire FUUUUUUUUUU

Never leave a parabolic mirror in the boot of your car. pic.twitter.com/sTKhr1YBh8

— ???? (@Alby) July 21, 2018

Oups...

flanker (./2798) :
et qu'un bit suffise à faire foirer la reconstruction (de mémoire, c'est le cas avec du RAID).

Je ne sais pas pour un NAS avec firmware intégré, mais pour un RAID du noyau Linux (mdraid), il est possible de reconstruire le RAID avec des disques partiellement lisibles en les copiant vers un disque neuf avec dd_rescue et puis reconstruisant le RAID avec ça. Les secteurs illisibles ou corrompus seront corrompus aussi dans le RAID reconstruit (le RAID les considèrera comme valides, mais les données contenues ne seront pas valides), mais les secteurs lisibles resteront intacts.

Cela dit, une défaillance matérielle peut souvent rendre tout le disque illisible, soit immédiatement, soit à force d'essayer de lire de mauvais secteurs (qui font entrer en collision la tête de lecture avec les plateaux en rotation, ce qui diffuse de la poussière sur d'autres endroits, ce qui cause de nouveaux chocs faisant cogner la tête de lecture aussi à ces endroits, propageant ainsi de plus en plus les erreurs).

(Ça édite beaucoup ici )

Mais pas pour rajouter un nouveau lien qui n'a rien à voir des semaines après le post édité.

C'est bien ce que je te reproche, aucun challenge!

ET MAINTENANT J'AI DE LA CRYPTO QUI FONCTIONNE EN DEBUG MAIS SE CASSE LA GUEULE AU MILIEU EN RELEASE
FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

squalyl te dira : "ne jamais coder la crypto soi-même"

... et vince hurlera "LA CHIFFRO !!!"

(Zerosquare > cela dit, il faut bien que quelqu'un s'y colle )

Non, mais franchement, s'il ne comprend pas pourquoi sa crypto ne fonctionne pas, ça craint! Je conseille d'utiliser des bibliothèques libres fiables codées par des experts en la matière.

Je conseille plutôt d'utiliser les appels au système, les bibliothèques libres ne sont pas standard !

J'suppose que du coup, OpenSSL, ca passe pas?

        context.Initialize();
        context.UpdateBigNumbers(t3);
        context.UpdateData(userHash, 20);
        context.UpdateBigNumbers(salt, A, B, K);
        context.Finalize();
        M1.SetBinary(context);

En release ca me calcule de la merde mais en debug tout va bien. (C'est juste un type qui sert de wrapper autour des fonctions SHA1 d'OpenSSL)

Pen^2 (./2815) :
Je conseille plutôt d'utiliser les appels au système, les bibliothèques libres ne sont pas standard !

Sur le système que j'utilise, les bibliothèques libres sont les "appels au système".

Warpten (./2816) :
En release ca me calcule de la merde mais en debug tout va bien. (C'est juste un type qui sert de wrapper autour des fonctions SHA1 d'OpenSSL)

Bon déjà, c'est tout con, mais serais-tu en train de mélanger un OpenSSL compilé en debug avec une application compilée en release? Le compilateur Visual C++, notamment, est connu pour ne pas du tout apprécier cela (contrairement à d'autres compilateurs, comme GCC, qui permettent le mélange). (Attention si tu utilises un mélange de compilateurs: MinGW, lui, compile toujours en "release" du point de vue de Visual C++. Le mode debug de MinGW est release + informations de débogage DWARF. En particulier, il n'utilise pas (par défaut) les bibliothèques debug de Visual C++, qui ne sont distribuées qu'avec Visual C++ et dont la redistribution est interdite.)

Rajoute des printf, ça corrige ce genre de problème

Qui a kidnappé Ximoon et poste à sa place ?!