Dynamische schijf gaat offline

[One_Gandalf]

Indien ik gegevens wil kopiëren of verplaatsen van dynamische schijf A (Maxtor 300GB SATA) naar schijf B (NTFS standaardschijf) dan gaat schijf A offline indien een bepaald aantal bytes wordt overschreden. De grens ligt bij ongeveer 80 MByte.

Als ik via schijfbeheer de dynamische schijf activeer dan kan ik hem weer normaal benaderen totdat ik weer teveel bytes tegelijk verplaats of kopieer naar een andere schijf.

Iemand een idee waar dit aan kan liggen. Op het moment dat de dynamische schijf offline gaat hoor ik de harde schijf ook tikken. Dit tikken is alleen hoorbaar als de schijf offline gaat. Bij het verplaatsen van kleinere hoeveelheden is de dynamische schijf 'geruisloos'.

In apparaatbeheer zie ik niet de merknaam van de schijf zoals bij de andere schijven. Er staat slechts 'Harddisk'.

Uitgeprobeerde zaken:
- een andere SATA-aansluiting
- uitzetten schrijfcache ; niet gelukt (deze optie wordt niet getoond bij apparaatbeheer)

[ Voor 15% gewijzigd door One_Gandalf op 04-01-2008 00:01 ]

[Fauna]

Aangezien je tikken hoort kan dit twee dingen betekenen:

• De schijf is plotseling uitgeschakeld. Dit zou kunnen liggen aan een (te) lichte voeding.
• De kop van de harde schijf maakt een crash. Dit zou betekenen dat je schijf eigenlijk al ten dode is opgeschreven. Controleer of je schijf geen beschadigde sectoren heeft.

Je problemen hebben waarschijnlijk dus niets te maken met de indeling (dynamisch), of de hoeveelheid data die wordt verwerkt. Eerder dat de schijf flink actief is en dat deze veel stroom trekt of resp. een specifieke locatie van de gegevens die je opvraagt.

Het feit dat je harde schijf niet met naam en toenaam vermeld staat in apparaatbeheer heeft waarschijnlijk met je SATA-controller te maken. Dit is niet erg, maar in dit geval kan Windows de schijf niet rechtstreeks benaderen omdat je waarschijnlijk een array hebt gedefinieerd in je controller.

[One_Gandalf]

Fauna schreef op woensdag 02 januari 2008 @ 11:34:
Aangezien je tikken hoort kan dit twee dingen betekenen:

• De schijf is plotseling uitgeschakeld. Dit zou kunnen liggen aan een (te) lichte voeding.
• De kop van de harde schijf maakt een crash. Dit zou betekenen dat je schijf eigenlijk al ten dode is opgeschreven. Controleer of je schijf geen beschadigde sectoren heeft.

Je problemen hebben waarschijnlijk dus niets te maken met de indeling (dynamisch), of de hoeveelheid data die wordt verwerkt. Eerder dat de schijf flink actief is en dat deze veel stroom trekt of resp. een specifieke locatie van de gegevens die je opvraagt.

Het feit dat je harde schijf niet met naam en toenaam vermeld staat in apparaatbeheer heeft waarschijnlijk met je SATA-controller te maken. Dit is niet erg, maar in dit geval kan Windows de schijf niet rechtstreeks benaderen omdat je waarschijnlijk een array hebt gedefinieerd in je controller.

Het probleem treedt totnogtoe op in elke van zo'n 5 directories indien ik via <Shift><PgDn> ongeveer minimaal 4 pagina's selecteer en vervolgens verplaats. Het lijkt dus niet lokaal op te treden (afhankelijk van hoe je lokaal definieert natuurlijk).

Ik heb geen array gedefinieerd. Ik zal eens een andere harde schijf op dezelfde aansluiting plaatsen en kijken of de merknaam dan wel wordt getoond in schijfbeheer.

Ik verwacht niet dat de voeding het probleem is. Dan zou ik hetzelfde probleem verwachten met mijn andere harde schijven.

Een check is een goed idee. Deze durf ik echter niet te doen omdat ik bang ben dat de schijf dan nog corrupter wordt (heb dit namelijk al eens meegemaakt bij een automatische check bij het booten van het systeem).

[Fauna]

One_Gandalf schreef op woensdag 02 januari 2008 @ 11:56:
Het probleem treedt totnogtoe op in elke van zo'n 5 directories indien ik via <Shift><PgDn> ongeveer minimaal 4 pagina's selecteer en vervolgens verplaats. Het lijkt dus niet lokaal op te treden (afhankelijk van hoe je lokaal definieert natuurlijk).

Het lijkt misschien regelmatig, maar door fragmentatie kunnen bestanden toch bij- of door elkaar staan zonder dat je het beseft.

One_Gandalf schreef op woensdag 02 januari 2008 @ 11:56:
Ik heb geen array gedefinieerd. Ik zal eens een andere harde schijf op dezelfde aansluiting plaatsen en kijken of de merknaam dan wel wordt getoond in schijfbeheer.

Ik zou je hierover niet al te druk maken. Mocht een andere schijf zich wel 'normaal' laten zien in apparaatbeheer kan er meer aan de hand zijn, maar het lijkt me niet.

One_Gandalf schreef op woensdag 02 januari 2008 @ 11:56:
Ik verwacht niet dat de voeding het probleem is. Dan zou ik hetzelfde probleem verwachten met mijn andere harde schijven.

Het kan zijn dat de ene schijf hier wat gevoeliger voor is dan de ander, of misschien zelfs dat de stekker niet goed aangesloten is. Het uitsluiten van componenten, in dit geval de voeding, kan nooit kwaad.

One_Gandalf schreef op woensdag 02 januari 2008 @ 11:56:
Een check is een goed idee. Deze durf ik echter niet te doen omdat ik bang ben dat de schijf dan nog corrupter wordt (heb dit namelijk al eens meegemaakt bij een automatische check bij het booten van het systeem).

Zolang je de optie /f niet aangeeft bij chkdsk zal ie geen fouten repareren. Dan voorkom je alvast dat kleine oppervlakkige fouten niet plotseling worden gerepareerd. Als dat in orde is, kun je dan een uitgebreide controle doen (/r). Deze zal echter altijd fouten corrigeren als hij deze vindt.

[One_Gandalf]

Fauna schreef op woensdag 02 januari 2008 @ 12:24:
Ik zou je hierover niet al te druk maken. Mocht een andere schijf zich wel 'normaal' laten zien in apparaatbeheer kan er meer aan de hand zijn, maar het lijkt me niet.

De schijf waarvan de merknaam niet wordt getoond in apparaatbeheer blijkt bij nadere controle een andere schijf te zijn die is aangesloten via een PCI Promise controller. Het klopt dat via de PCI Promise controller geen merknaam wordt getoond. Is dus geen probleem.

Fauna schreef op woensdag 02 januari 2008 @ 12:24:
Zolang je de optie /f niet aangeeft bij chkdsk zal ie geen fouten repareren. Dan voorkom je alvast dat kleine oppervlakkige fouten niet plotseling worden gerepareerd. Als dat in orde is, kun je dan een uitgebreide controle doen (/r). Deze zal echter altijd fouten corrigeren als hij deze vindt.

Ik heb Seatools gedownload en heb momenteel een lange test (Long Drive Self Test) draaien. De korte test (Short Drive Self Test) verliep goed.

[ Voor 5% gewijzigd door One_Gandalf op 02-01-2008 23:03 ]

[One_Gandalf]

Resultaten van de test met SeaTools for Windows :

• Short Drive Self Test : Pass
• Long Drive Self Test : Pass
• Identify : Pass
• Short Generic : Pass
• Long Generic : Pass

De gegevens die de test Identify opleverde:
Model: Maxtor 7V300F0
Serial Number: V608ED0G
Firmware Revision: VA11
Identify - Pass 3-1-2008 21:52:42
Smart: Supported and enabled
48 Bit Addressing: True
Max LBA: 586114704
Host Protected Area Feature Set Supported: 2
Power Managment Feature Set: Suported and enabled
Security Mode Feature Set: Supported not enabled
Set Max Security Extension Supported: 1
Advanced Power Managment Feature Set: Supported not enabled
Download Microcode Supported: False
SMART Self Test Supported: True
SMART Error Logging Supported: True

Het lijkt dus dat de schijf fysiek in orde is.

Er is dan dus of sprake van corrupte data of er zijn problemen met de stroomvoorziening? Wanneer er poblemen zijn met de stroomvoorziening dan zou ik ook tijdens de lange tests (meer dan een uur) verwachten dat de schijf er uit knalt. Dit gebeurde echter niet.

De schijf uit het systeem gehaald. Het stof aan de achterzijde weggezogen. Weer terug geplaatst. Nu een kopie naar een andere harde schijf dan de vorige keer. En zie nu verloopt het zonder fouten. Mogelijke redenen:

1. Achterkant stofvrij gemaakt
2. Powerconnectors aangedrukt
3. Kopie naar een andere harde schijf
4. De testen met Seatools (alhoewel de testen alleen lezen)
5. Iets anders

Ik moet wel melden dat een van de schijven niet werd herkend bij het booten (die op de Promise Controller). Dit zou een reden kunnen zijn voor een betere stroomverzorging.

[ Voor 23% gewijzigd door One_Gandalf op 04-01-2008 00:03 ]

[One_Gandalf]

Het commando 'chkdsk /f' uitgevoerd op de partitie T: op de probleemschijf. Er werd het een en ander hersteld. De logische data was dus corrupt geworden door het meerdere malen offline gaan van de schijf.

De schijf zit nu op een andere SATA-aansluiting. Hiervoor zat de schijf op een SATA-aansluiting van de chip Sil3112. Ik heb op het web gelezen dat deze chipset problemen kan geven met een Maxtor-schijf. Morgen zet ik de schijf weer op de Sil3112 en kijk of het probleem dan terug keert.

Ik heb al een nieuwere driver-versie voor de Sil3112 gevonden op de site van de fabrikant van mijn moederbord GigaByte.

Update
Met de schijf op de Sil3112 aangesloten gaat het kopiëren naar een andere schijf nu ook goed. Het lijkt er op dat het probleem hiermee opgelost is. Ik weet echter nog niet de oorzaak van het probleem. Ik zal dit in de gaten houden.

Update
De schijf op de Promise controller wordt weer herkend na het los- en vastmaken van de SATA-connectors. Deze maken blijkbaar niet altijd een goed contact. Na deze actie gaat het kopiëren nog steeds goed. De volgende voorzichtige cunclusies volgen dan:

• De schijf is fysiek gezien gezond
• Het probleem is niet veroorzaakt door de Sil3112 chip
• Het probleem is niet veroorzaakt door de voeding
• Het probleem is veroorzaakt doordat de logische data op de schijf corrupt was waardoor Windows besloot om de schijf offline te zetten

[ Voor 40% gewijzigd door One_Gandalf op 06-01-2008 11:02 ]