données corrompues sur transferts contrôleur JMicron - Stockage/Sauvegarde - Windows & Software
Marsh Posté le 19-06-2009 à 20:36:09
1 mois plus tard : up sans y croire
Juste compris qu'au vu de l'époustouflante fiabilité de ce contrôleur, mieux valait s'en passer.
Rest in peace JMicron.
Marsh Posté le 19-06-2009 à 21:30:22
C'est assez aléatoire les contrôleurs JMicron : parfois ça passe, parfois ça passe pas du tout.
Si c'est possible, toujours préférer le raid géré par le southbridge en natif (surtout si c'est du matrix raid) : ou alors, avec de l'argent, utiliser une carte dédiée pour le raid hardware.
Marsh Posté le 19-06-2009 à 22:11:56
Ah merci un petit écho !
Citation : Si c'est possible, toujours préférer le raid géré par le southbridge en natif (surtout si c'est du matrix raid) |
J'en étais arrivé à la même conclusion.
Justement, après-coup, je me félicite d'autant plus d'avoir opté pour le semi-soft RAID Intel
Simplement sur la P5K Premium c'est frustrant de ne plus pouvoir profiter de l'eSATA depuis que je suis passé en RAID sur les ports Intel.
(Avant ça marchait bien)
Citation :
|
Ben... sur ma Gigabyte je pensais peut-être un jour configurer un RAID 0 de stockage sur les ports JMicron (pour des rushes vidéo HD non compressés très lourds)... jusqu'à ce que je constate les limites des contrôleurs JMicron sur l'Asus. Dans l'idée de faire des économies, quoi...
Mais si ces puces n'arrivent déjà pas à dialoguer avec du RAID, qu'est-ce que ça donnerait pour le gérer complètement ?
En effet, quand ce sera moins tendu (financièrement ), on verra pour du contrôleur hardware.
... Pas pour tout de suite... En ce moment c'est ceinture. Et ça va durer un peu.
Merci encore pour la réponse !
Marsh Posté le 19-06-2009 à 22:35:40
Comme le disait mon mentor : le raid semi-logiciel ou logiciel, si ce n'est pas du Intel, c'est du suicide
Et il n'a pas tort
Marsh Posté le 19-06-2009 à 22:53:23
Oui ton mentor n'a pas tort
Mais semi-logiciel seulement tu veux dire ?
Parce que 100% logiciel, Intel n'intervient plus, non ? Juste la qualité du code.
Et selon les usages, sous Linux ou même Windows, c'est parfois une bonne solution d'ailleurs (à condition que le proco suive).
Meilleure sûrement qu'un mauvais fake.
Marsh Posté le 17-05-2009 à 14:39:10
Bonjour,
J'espère poster dans la bonne section, même si mon problème est en même temps matériel.
Voilà : j'ai installé un RAID Matrix ("fake" RAID donc) sur 1 PC. (Carte mère Asus P5K Premium)
2 HDD : 55 Go RAID 1 (OS + données sensibles) / 355 Go RAID 0 (médias montage vidéo).
Très content du contrôleur Intel (ICH9R DO SATA RAID controller). Même si ce n'est "que" du RAID semi-soft. (Ce RAID 0 permet de monter souple & avec de la marge des rushes HD assez lourds.)
Le problème arrive avec le contrôleur JMicron !!
> transfert RAID 1 (contrôleur Intel) => disque eSATA (port JMicron) = fichiers régulièrement corrompus.
> gravures de fichiers depuis RAID 0 (Intel) => graveur Sony en IDE (port "JMicron controlled" ) = erreurs de gravure, données corrompues.
> transferts RAID 0 (Intel) => disque eSATA (port JMicron) = même mayonnaise.
Ce sont d'ailleurs des erreurs lors des checks post-gravure qui m'ont mis la puce à l'oreille pour ces problèmes.
Chaque fois il suffit de calculer la somme md5 à l'arrivée pour voir que les .iso finissent ratatinés .
Par contre, les gravures RAID 1 > IDE (graveur Sony, même port JMicron) = sans problème.
Et les transferts via le BUS USB = nickel 100% (heureusement !).
Voilà. Je sais que les contrôleurs JMicron n'ont pas bonne réputation... Mais quand même !
Autant ne même pas les intégrer aux cartes mères si c'est ça.
Ou alors j'ai loupé quelque chose ???
NB : drivers JMicron à jour.
NB2 : dans le BIOS, j'ai repassé le contrôleur JMicron de AHCI vers IDE, mais je doute que ça change quoi que ce soit.
Toute lumière sera bienvenue,
Ou un retour d'expérience similaire (problèmes JMicron du même type, etc.)
Merci d'avance !
Message édité par zoroastre94 le 18-05-2009 à 10:54:01