Corruzione Dati su HD in mirroring su Controller PCI IDE RAID

[NetUnix]

Un bel problema: i dati trasferiti sui 2 HD in mirroring installati su un controller IDE RAID PCI HighPoint rocketRAID133 risultano diversi da quelli di origine presenti sul disco di avvio o su un altro pc e trasferiti via Ethernet.
CONFIGURAZIONE DEL MIO SISTEMA

MotherBoard: Supermicro P3TDDE (via apollo Pro 266) http://www.supermicro.com/products/m...VIA/P3TDDE.cfm
CPU: 2 PIII-S Tualatin 1,4GHz
RAM: 3x512MB SDRAM
VIDEO: GeForce4MX
Controller IDE PCI aggiunto: Hihpoint Rocket133(HPT 302) http://www.highpoint-tech.com/USA/r133.htm su cui c'è il WD800JB di avvio
Controller IDE RAID PCI aggiunto: Hihpoint RocketRAID133 (HPT372N) http://www.highpoint-tech.com/USA/rr133.htm su cui ci sono 2 x WD1600JB in Mirroring (Raid 1) installati sui due canali ide raid in master. Sono settati come unica partizione da 160GB
Drive Ottici: Plextor Premium IDE2 master, Yamaha F1 IDE2 slave, Liteon167T IDE1 Master, BenQ 1640 IDE 1 slave
OS: Windows XP SP2

ANALISI DEL PROBLEMA
- i dati copiati sui dischi in mirroring risultano diversi dai sorgente
- i dati copiati dal disco di avvio a quelli in mirroring sono diversi; è vero anche il viceversa ma il n° di file diversi è inferiore
- i dati copiati dal disco di avvio al disco di avvio sono identici
- i dati copiti da altri pc via LAN al disco di avvio sono identici mentre quelli copiati ai dischi in mirroring sono diversi
- i dati copiati dai dischi in mirroring ai dischi in mirroring sono diversi
- il bios di tutte e 2 i controller sono aggiornati all'ultima relese e i driver installati sono quelli compatibili col relativo bios
- il bios della mobo è l'ultimo
- i driver del chipset sono quelli di microsoft inclusi in windowsXP SP2

PROVE EFFETTUATE
- installazione dei Via4in1
- ricostruzione dell'array
- formattazione dischi in mirroring e loro controllo con utility WD di diagnostica(sono ok)
- disabilitazione da bios della mobo del DMA transfer

IPOTESI
- supporto LBA inadguato?
- NTFS?
- Problemi di incompatibilità controller - HD western digital >137GB?


sono disperato. Aiutatemi

[NetUnix]

pensavo....

è possibile che gli hard disk non siano perfettamente sincronizzati in modo tale che quando si accede in lettura ad un file che viene letto su entrambe i dischi avvenga una lettura "sfasata" dei bits che lo costituiscono?

non credo di aver scritto il pensiero in modo chiaro ma è di difficile resa....

quando ho impostato l'array mirroring da bios del controller ho scelto l'opzione: "create array only" anzichè l'opzione "create array and duplicate".

può centrare qualcosa?

un altra cosa strana che ho notato: non mi fa cancellare alcune cartelle/files dicendo che la cartella non è vuota....Ma chi è che comanda?
l'unico modo per eliminarli è quello di formattare

[MM]

Se hai creato l'array e non duplicato i dati, all'avvio avrebbe dovuto chiederti se volevi duplicarli
Ora magari verifica qual è il disco "buono" (dovresti poter avviare con un solo disco) e poi magari chiedi la duplicazione da questo disco all'altro

[NetUnix]

Originariamente inviato da MM

Se hai creato l'array e non duplicato i dati, all'avvio avrebbe dovuto chiederti se volevi duplicarli
Ora magari verifica qual è il disco "buono" (dovresti poter avviare con un solo disco) e poi magari chiedi la duplicazione da questo disco all'altro

il fatto è che ho creato l'array con i dischi completamente vuoti(quindi non capisco la necessità di duplicarli...cosa verrebbe duplicato se i dischi sono vuoti e non ancora formattati?). Dopodichè ho copiato sopra un po di dati, quindi controllata la corrispondenza(con -Fc/b o CDcheck)...che non c'è

[MM]

Se sono vuoti, allora rifai tutto da capo, che è meglio
E comunque lascialo duplicare: nessuno sa che cosa esattamente fa, a parte duplicare eventuali dati

[NetUnix]

Originariamente inviato da MM

Se sono vuoti, allora rifai tutto da capo, che è meglio
E comunque lascialo duplicare: nessuno sa che cosa esattamente fa, a parte duplicare eventuali dati

ok proverò incrociando le dita....anche se ci vorranno 7 ore

[NetUnix]

Originariamente inviato da NetUnix

ok proverò incrociando le dita....anche se ci vorranno 7 ore

Niente da fare: NON è servito a niente.
ho scritto al supporto dell'highpoint e mi hanno risposto che è un problema sconosciuto.....

[MM]

Andiamo bene....

[NetUnix]

proprio nessuna idea?

[NetUnix]

uppetto x la speranza

[NetUnix]

AGGIORNAMENTO SITUAZIONE

dalle prove da me effettuate ho dedotto quanto segue:

L'unica configurazione hardware che consente il corretto funzionamento esente dagli errori di cui sopra è quella in cui i 2 HDs sono collegati sullo stesso canale come master e slave. La configurazione con i 2 hard disk ciascuno su uno dei 2 canali, 1 e 2, del controller settati come drive singoli, provoca errori nel trasferimento dati da e verso il controller.
Ho notificato la cosa alla HighPoint.....vedremo cosa rispondono: spero qualcosa di piu utile e intelligente di un "this is an unknown issue"

I cavi usati sono quelli forniti in dotazione col controller: inoltre li ho testati, e ho testato altri cavi sul controller tanto da escluderli categoricamente come causa.
Non so suppore quale sia il problema

[NetUnix]

dall 'HighPoint nessuna risposta....

[Marco71]

...mi sono balenati nella mente subito i problemi di gestione del bus P.C.I a carico dei chipset per Intel Pentium III prodotti da VIA Technologies e derivati dal nucleo dell'Apollo 133...
Problemi che sono conosciuti anche dalla stessa VIA e riguardano la corruzione dei dati in transito sul bus P.C.I (nostante ogni trasferimento dati sia "protetto" da parità).
Oltre a ciò esistono anche problemi dovuti al timer di latenza di cicli concessi ad ogni Master durante l'attività sul bus (dei veri e propri "buchi" nei cicli riguardanti le transazioni di lettura e scrittura).
Mi potresti gentilmente specificare in quale slot P.C.I hai il controllore R.A.I.D ?
Questo stante il fatto che su molte motherboard nemmeno esiste "simmetria" di gestione del bus P.C.I (oltre che come livelli di interruzione anche come spazio di memoria assegnato).
Ti dico anche che non mi fido più del chip HighPoint HPT370A che credo equipaggi anche il tuo controllore dato che una Adaptec 1200A (con HPT370A a bordo) mi ha dato seri problemi non più tardi di tre settimane fa.
Adesso i prodotti Highpoint sono sulla mia blacklist ed il fatto che tu abbia ricevuto poca assistenza dalla casa "madre" mi insospettisce non poco (e mi preoccupa)...è successo a me anche con PacificDigital -> supporto postvendita con la stessa cardinalità di Aleph Zero.
Per avere conferme "schiaccianti" ai miei timori servirebbe un analizzatore di protocollo bus P.C.I oppure la mega-super suite SCSIToolbox che è in grado di analizzare ogni tipo di connessione bus per hard disk (e periferiche in genere) sia essa di tipo A.T.A (seriale o parallela), A.T.A.P.I, S.C.S.I, S.A.S ecc.
Ahimè i chipset VIA sono da molto tempo nella mia suddetta blacklist...nessuno si ricorda i problemi di corruzione dati associati alla combinazione di un noto chipset per A.M.D Athlon e notissima scheda audio ?
Fammi sapere se hai nel frattempo risolto il problema...
Grazie.

Marco71.

[NetUnix]

Rispondo molto volentieri al tuo acutissimo e completo intervento.

1. il chip del controller highpoint rocket Raid 133 è l' HPT372N aggiornato all'ultimo bios disponibile sul sito (ovviamente i driver installati sono della stessa versione del bios)
2. tale controller è collocato nello slot pci numero 2 (sul numero 1 c'è l'altro controller Highpoint IDE NON Raid HPT370 che gestisce il solo disco di avvio)
3. per ora ho risolto il problema ponendo i 2 dischi sullo stesso canale del controller come master/slave: con questa configurazione pare non esserci corruzione dati (almeno fino ad ora)
4. il fatto che il supporto dell'highpoint si sia limitato a rispondere solo alla mia prima mail con un : " this is an unknown issue" è piuttosto irritante tanto che continuerò a bombardarli di mail.
5. il chipset della motherboard è così costituito: Northbridge = VT8633, Southbridge = VT8233

pensi che spostando il controller su un altro slot pci(che non sia il primo altrimenti poo potrei avere difficoltà a fare boot dal disco di avvio) potrebbe risolvere magicamente il problema?

[Marco71]

Risolvere "per magia" purtroppo penso di no.
Puoi provare per prima cosa ad invertire l'ordine di inserimento dei due controllori dato che l'HPT370 è molto simile all'HPT370A che mi ha dato il problema di cui parlo (proprio con una matrice R.A.I.D-1 composta da due hard disk P-A.T.A e "gestita" da un HPT370A).
Scambia le schede di posto e prova a comprimere e decomprimere archivi con Winzip o simili controllando che non si verifichino errori di C.R.C.
Grazie.

Marco71.

[NetUnix]

Originariamente inviato da Marco71

Risolvere "per magia" purtroppo penso di no.
Puoi provare per prima cosa ad invertire l'ordine di inserimento dei due controllori dato che l'HPT370 è molto simile all'HPT370A che mi ha dato il problema di cui parlo (proprio con una matrice R.A.I.D-1 composta da due hard disk P-A.T.A e "gestita" da un HPT370A).
Scambia le schede di posto e prova a comprimere e decomprimere archivi con Winzip o simili controllando che non si verifichino errori di C.R.C.
Grazie.

Marco71.

Chiedo Scusa:
nella fretta ho commesso un errore: il chip del controller IDE che gestisce il solo disco di avvio è l' HPT302 e non l'HPT370.
Cmq proverò quanto prima possibile ad invertire l'ordine dei 2 controller sperando di non perdere il boot. Infatti avrei fatto volentieri a meno di usare un controller Raid aggiuntivo dato che questa motherboard ospita un controller Promise Fastrack 100 integrato. Il problema fu che questo controller, con l'attuale bios della mobo, non supporta l'indirizzamento a 48bit LBA. Per consentirgli di rilevare gli hard disk che devo usare (160GB) aggiornai il bios della mobo con una versione beta (consigliata da supermicro) che avrebbe introdotto tale supporto. Tuttavia con il bios beta non era piu possibile fare il boot dal disco connesso al controller HPT302. Feci varie prove per trovare una soluzione (cambiare slot pci delll'HPT302, pacioccare con impostazioni di boot e IRQ nel bios...) ma non ci fu nulla da fare. Tuttavia appena disabilitavo il controller Promise raid integrato tramite apposito jumper sulla mobo, il boot dal disco sull'HPT302 era ripristinato. Alla fine mi decisi di usare questo controller HPT372N che cmq già avevo e disabilitare quello onboard.