Minimale data corruptie bij copieren naar externe harddisk?

[PeterPan]

Gisteren kopieerde ik een map met 21 video bestanden van in totaal ~15GB vanaf mijn fileservertje, via mijn PC, naar een externe USB harddisk:
RAID5 array (Windows 2008R2 NTFS filesystem) -> Gigabit netwerkje met switch -> Windows 7 PC -> USB harddisk.

Het ging hier om een seizoen van een T.V. serie die ik op een andere PC/internet verbinding wilde seeden. Tijdens het hash checken op de andere PC kom ik er achter dat er in 1 van de files een klein verschil zit en de hash check dus niet correct is. Het gaat om een van de laatste bestanden in de directory (maar niet het laatste bestand) in de laatste 20% van de file.

Ik heb dit gecontroleerd door een byte voor byte binary compare te doen middels de compare functie in Total Commander en zie inderdaad dat er tussen het bestand op de fileserver en op de USB disk twee (aaneengesloten) bytes anders zijn (niet een 00 of FF oid, gewoon random anders).

Ik heb de externe schijf na het kopiëren netjes afgesloten.
Ik heb een chkdsk /f /r gedaan op de USB disk; geen fouten.
Ik heb in Windows 7 een full format gedaan op de USB disk en nogmaals een chkdsk /f /r; nog steeds geen fouten of bad sectors.
Ik heb de SMART waarden van de USB disk bekeken en zie geen re-allocated sectors oid.

Waardoor kan dergelijke minimale data corruptie optreden?
Ik ben er eigenlijk altijd vanuit gegaan dat zowel op het TCP/IP netwerk als bij het schijven naar externe schijven via USB altijd end-to-end checks gedaan worden.

Nu gaat dit om een video bestand en zijn die twee omgevallen bytes waarschijnlijk niet hoorbaar of zichtbaar maar als het om een zip/rar/exe had gegaan had deze waarschijnlijk geheel defect geweest. Het is puur toevallig dat ik er middels een hash check van de torrent client achter kom.

Iemand enig idee waardoor dit kan komen en waarom Windows dit niet detecteert?

[Nielson]

Heb je het geheugen ook gecontroleerd (met bv memtest86+)? Geef verder even de specs van de gebruikte hardware aan.

[RemcoDelft]

PeterPan schreef op woensdag 05 oktober 2011 @ 11:17:
Waardoor kan dergelijke minimale data corruptie optreden?
Ik ben er eigenlijk altijd vanuit gegaan dat zowel op het TCP/IP netwerk als bij het schijven naar externe schijven via USB altijd end-to-end checks gedaan worden.

Ik kwam lang geleden specs van harde schijven tegen, waaruit bleek dat er eens in de zoveel (orde-grootte 10¹⁵) bitjes een niet-detecteerbare fout optreedt. Het kan dus gewoon toeval zijn.
Ik heb zelf ook wel problemen gehad met lange netwerkkabels (60 meter met halverwege een switch), waarbij files van een GB meestal wel een bitje "anders" hadden.

[PeterPan]

Nielson schreef op woensdag 05 oktober 2011 @ 12:09:
Heb je het geheugen ook gecontroleerd (met bv memtest86+)? Geef verder even de specs van de gebruikte hardware aan.

In de server zit 8GB ECC geheugen die ik ongeveer 15uur getest heb met memtest86+.
In de PC zit 4GB non-ECC geheugen, dat zal ik ook eens een nachtje testen.

[PeterPan]

RemcoDelft schreef op woensdag 05 oktober 2011 @ 12:15:
[...]

Ik kwam lang geleden specs van harde schijven tegen, waaruit bleek dat er eens in de zoveel (orde-grootte 10¹⁵) bitjes een niet-detecteerbare fout optreedt. Het kan dus gewoon toeval zijn.
Ik heb zelf ook wel problemen gehad met lange netwerkkabels (60 meter met halverwege een switch), waarbij files van een GB meestal wel een bitje "anders" hadden.

Maar zowel TCP/IP als het Windows sharing protocol zitten toch vol met CRC checks e.d.?

Ik kan me nog wel herinneren dat je in de tijd van de floppies de 'verify on write' kon uitzetten om het schrijven te versnellen. Staat dit tegenwoordig standaard uit en gaat het OS er vanuit dat een harddisk nooit schrijffouten maakt oid?

[redfoxert]

Hiervoor gebruik ik filecopy tools die naderhand nog een verify uitvoeren, zoals TeraCopy. En sowieso nooit moven, altijd kopieren. Deleten kan altijd nog handmatig naderhand.

[Tens]

Bijzonder, het moet haast wel een leesfout zijn, communicatie en schrijven is volgens mij dichtgetimmerd met diverse checks.
Hoe lang duurde het kopiëren?


aanvulling; staat er iets in de logfiles van je server?

[ Voor 16% gewijzigd door Tens op 05-10-2011 13:01 ]

[CaptJackSparrow]

In dit topic doe ik o.a. verslag van mijn vreemde ervaringen met externe USB behuizingen. Verder staan er wellicht relevante opmerkingen in.

Is dit een nieuwe behuizing/schijf? Is het systeem overclocked?

[PeterPan]

Tens schreef op woensdag 05 oktober 2011 @ 12:59:
Bijzonder, het moet haast wel een leesfout zijn, communicatie en schrijven is volgens mij dichtgetimmerd met diverse checks.
Hoe lang duurde het kopiëren?

aanvulling; staat er iets in de logfiles van je server?

Het kopiëren ging met normale USB 2 snelheid, ongeveer 20~25MByte/sec.
In het eventlog van de Windows server kan ik niets vinden. In de log van de Intel server management software zie ik wel 1 gecorrigeerde ECC memory fout maar die is van ruim een jaar geleden. Wel interessant om te zien dat het mainboard dit soort errors kan detecteren en corrigeren.

[PeterPan]

CaptJackSparrow schreef op woensdag 05 oktober 2011 @ 13:06:
In dit topic doe ik o.a. verslag van mijn vreemde ervaringen met externe USB behuizingen. Verder staan er wellicht relevante opmerkingen in.

Is dit een nieuwe behuizing/schijf? Is het systeem overclocked?

Ik zal dat topic waar je naar linkt zeker doorlezen, bedankt.
De externe schijf is een jaar of twee oud. Het is een Platinum met intern een 320GB schijf van WD.
Mijn systeem is niet overclocked en afdoende gekoeld.

[D4NG3R]

Ik weet dat het ongewoon is: Maar is de server overgeklokt? Een brakke overklok kan namelijk zorgen voor corrupte data af en toe.

Laatste post over het hoofd gezien -> Nee dus.

[ Voor 18% gewijzigd door D4NG3R op 05-10-2011 13:21 ]

[Tens]

PeterPan schreef op woensdag 05 oktober 2011 @ 13:15:
[...]


Het kopiëren ging met normale USB 2 snelheid, ongeveer 20~25MByte/sec.
In het eventlog van de Windows server kan ik niets vinden. In de log van de Intel server management software zie ik wel 1 gecorrigeerde ECC memory fout maar die is van ruim een jaar geleden. Wel interessant om te zien dat het mainboard dit soort errors kan detecteren en corrigeren.

Ook geen temperatuur alerts?


Ik zou wel dezelfde actie nog een aantal keer doen om te kijken of het iets reproduceerbaars is, of een incidentje.

[Mijzelf]

PeterPan schreef op woensdag 05 oktober 2011 @ 12:50:
Maar zowel TCP/IP als het Windows sharing protocol zitten toch vol met CRC checks e.d.?

Dat valt tegen. Ieder pakketje heeft een 16 bits CRC. Dat betekent dus dat als je de payload vervangt door ruis, je een kans hebt van 1 op 64k dat de checksum klopt. Hoe het zit met 'goede' payload waarin je een paar bits omgooit weet ik niet. Ik denk dat je in elk geval minstens 2 bytes moet verminken om de checksum weer kloppend te krijgen.

[jan99999]

Vroeger dit ook gehad, 1 op de 10 files was er een beschadigd, met via netwerk versturen.
Oorzaak was firewall, verwijderd, andere erop, toen was het weer goed.(1 week gezocht).

Kan dus hardware of software zijn, of driver niet goed, kabel niet goed.
Check voor netwerk fouten dus verloren paketten.
Verwijder firewall en virusscanner, en testen.

Zelf doe ik op alles testen dmv 40Gb in een map zetten en daar par2 op zetten, dan 40Gb over het netwerk sturen.
Ook voot externe hd's doe ik dit, vroeger externe hd gehad die op 1 pc uitviel en op andere pc wel goed werkte.
Waarom 40 Gb, bij kleinere files merkte ik vaak niks en bij grote files waren vaak problemen.