SMPFR

powa, pas mal.

enfin si il faut calculer le checksum a chque E/S ca va en boufé du CPU !

Je connais moins les 2 autres, mais aux dernières nouvelles Oracle facture justement suivant les CPUs ...

du coup... je comprends bien qu'ils veulent que leurs clients fassent un maximum de contrôles sur leurs données.

Bon me suis remotiver pour check mes data, histoire d'avoir une référence d'état pour le futur lointain

Donc avec MD5sums ca donne:

Les problèmes:

-Le soft crée un seul fichier MD5 par dossier de dossier de fichier.

-Donc a moins de manuellement relancer le soft pour crée un fichier MD5 par dossier de fichier, le truc englobe tous les dossiers et fichier du dossier sible

-le soft crée des erreur a la création de MD5 si un fichier a dans son titre, des caractères symbolique

-Le soft et + ou - BI treadé, donc CPU limited dans les check.

-l'ajout de fichier dans un dossier checker ne crée pas d'erreur l'or d'une verif de check.

-Mais un changement du nom d'un fichier checker, oui. Normal.





Il faut que je trouve un system de check md5 incrémentable.
ex: réutilisé un fichier MD5 déjà existant qui ne va pas re check les fichier déjà checker, mais ajouter a la liste les nouveau.
Et ceux, de manière automatique.


le soft peut être lancer en multi session.
Donc on peut cumuler les check.


Mais bon, de manière empirique, le system marche plutôt bien.




Mon but étant de conserver ces data en l'état, pour de longue, très longue duré.
Je dédierais des DD en stockage ''mort" pour la conservation.

Actuellement j'ai pratiquement 12TB de data a traité
Qui seront ensuite compresser et crypté.

Tu veux un checksum de chacun de tes fichiers en fait ?

Bah ça le fait déjà.

Je voudrai enfaite, un fichier MD5 par dossier de fichier, aux lieux d'un fichier MD5 par dossier de dossier.

Ca facilitera le check spécifique et la misa a jours par dossier de fichier si modification des fichiers contenus.

Me semble que tu peux le faire avec le soft MD5 Checksum. C'est de la ligne de commande par contre

un soft a interface serai plus pratique mais au pire ...

vais chercher pour les commande.

peut etre une possibilité d'utiliser nos ASIC bitcoin;
http://ocr.altervista.org/wordpress/footprint/
http://slavasoft.com/hashcalc/index.htm

Finalement c'est que des machine taillée specifiquement pour du sha (256 ou 512 au moins de ce que je sais, peut etre tous les genre, voir meme MD5)
Il suffirai de tailler un log propre pour le prendre en compte et roulez jeunesse

woowww ca serai bon ca.

la ca m'interesse.

enfin il sufi de trouver un soft multitread et rulez pour mes ti cpu.

bah mieux; un seul asic te donnerai la puissance de plus ou moins 30 000 de tes cpus sur du sha256 (pour le asic 36Ghash par exemple...)

Ha OK bon ben need it

Avec une telle puissance de calcul sur le hash, ça vaudrez le coup d'intégré la vérif. de MD5 plus en profondeur dans le fonctionnement du system de fichier.

Ha OK bon ben need it

Avec une telle puissance de calcul sur le hash, ça vaudrez le coup d'intégré la vérif. de MD5 plus en profondeur dans le fonctionnement du system de fichier.

Si il y en a qui veulent se mettre au dev, je pense que dans un an, voir moins avec les FPGA qui vont pas tarder a ne plus minner, ça va bien se vendre/se dll

Dès que j'ai un peu de temps je te ferais ça avec md5sum

Euh pour le Bitcoin miner je vois pas comment il peut gérer du md5, c'est pas le même algo... La longueur de clé peut-être

du sha256, le md5 est en voie de disparition

Tu parlais de calculer du MD5 avec le miner je crois (ou j'ai mal compris ?). Dans ce cas ça sera probablement impossible vu que c'est pas les mêmes algos. Sinon, je vais voir pour détourner le BTC miner sur du calcul de hash SHA, ça m'intéresse pour générer des rainbow tables entre autres. Dans le sujet de ce topic, pourquoi pas faire calculer ça à un miner, par contre faut boit les bottlenecks (rapidité de lecture du disque ou par le débit USB, m'étonnerait que l'ASIC sature tout seul)

ça sera sans doute le disque, les debit transmis seront sans doute aussi faibles que avec le minning...
mais oui, bien sur. d'autant qu'il serait dommage de n'utiliser que du md5, alors que la puissance dispo permet largement de faire du sha256, en mettant les goulots d’étranglement ailleurs...

pour faire ca tu couple asic + ram disk ^^

bah comme screené plus haut, les débit de lecture sont de 75MB/s pour une puissance de hach qu'il faudrait estimer histoire de connaitre le ratio puissance de hash/ bande passante.

Mais ca ne doit pas être énorme.
Oui l'usb sera un facteur limitant mais surement pas le PCIE (si ASIC en carte pcie existe).

ramdisk usless car c'est le lien config / asic qui posera problème avant le lien system de stockage/config.

et mes 11.5T de data sont pas encore sur DD ram
- SSD bientôt peut être.

Hm dans le cadre d'un asic qui lit des données pour en donner le sha correspondant, le facteur limitant ça sera plus la vitesse de lecture du disque que l'usb

bah non, ca sera clairement l'usb.

Hmm dans le cadre de ce que tu veux faire c'est l'asic qui doit voir le fichier en input pour sortir le hash, donc théoriquement t'as raison, 75Mo/s est supérieur aux 480Mbps (60Mo/s) théoriques de l'usb 2.0. En pratique ça sera p'têtre le cas sur des gros fichiers mais probablement pas sur les petits

sisi méme sur les petit, latence de l'usb ca fait très mal VS du sata ou raid sur contrôleur pcie/ssd ou meme DDRAM ...

L'usb sera TJ moins perf a tous niveaux.

need un asic en pcie, il arrive a intercom les virtex avec proc en passant par le QPI.
A voir ce qui est possible de faire avec certain asic, même si l'archi n’a rien à voir.

Faut pas rêver, il ne sera pas en PCI-e. Vu la taille que ça doit faire (20x10cm de mémoire à quelque chose près) et le refroidissement qu'il faut (conso estimée 200/300W), et surtout la R&D qui est plus simple pour de l'usb... C'est pas les ASICS pour du Bitcoin qui s'emmerderont à prévoir tout ça

HA BON ??? c'est si ENORME que ca.
clair que la ...

si ta des lien de produit deja existant ... je trouve rien