[Debian] RAID met lees-schrijf verificatie?

[MisterE]

Na de nodige problemen met data corruptie in een RAID5 setup ben ik erachter gekomen dat 2 van mijn (proef)schrijven bad sectors hadden. Helaas bleek mdadm daar totaal geen probleem van te maken. Ik kon vrolijk formatteren en er softraids van maken.

Nou is mijn intentie om een beetje degelijke backup fileserver te maken. En het heeft weinig zin als er parity wordt berekend over corrupte data, of opgeslagen word op een slechte schijf.
Is er niet een optie die ook controleert wat er opgeslagen word? (ik snap dat de performance dan totaal in elkaar stort)

Of zijn er nog andere oplossingen hiervoor? Het enge was dat e2fsck, badblocks en "hdd generator" geen problemen gaf. Pas toen ik de schrijf-lees optie ( badblocks -w -v -s /dev/hdc > ~/hdc.txt) van badblocks gebruikte viel ie door de mand.

[Verwijderd]

Je wil dus eigenlijk een tool die de gezondheid van je HD's meet ?

Smart-monitoring ?

[MisterE]

Weet SMART dan dat ie een leesfout/schrijf fout maakt? Want dat zou betekenen dat alles wat ie wegschrijft ook weer zou moeten inlezen. Ik weet niet of HD's dat standaard doen?

[Verwijderd]

Nee, SMART checkt alleen je HD op hoe snel hij dood gaat, of bijna... waarom zou je een lees of schrijffout willen checken ? Daar is SMART nu juist voor.

Gaat je veel performance kosten anders, niet van toepassing dus.

[MisterE]

nou, het formateren en maken en gebruiken van raids ging dus zonder problemen (met bad sectors). Hierdoor ontstonden dus corrupte bestanden. Als SMART me dat wel kan melden is er geen probleem, maar ik wil wel zeker weten dat ik de juiste data terug krijgt.

Nou heb ik net de smartmontools geinstalleerd en met smartctl de 1.7GB schijf gecontroleerd. Schijnbaar is deze nog van de ATA 2 versie waardoor die niet uitgelezen kan worden.
Ik heb ook nog een 2.6GB liggen maar die kreeg ik net ff niet aan de gang. (bios ziet hem niet).

En anders heb ik toch liever een optie die nog eens controleerd wat ie wegschrijft...

[SambalBij]

Bij een RAID5 array zou die controle er gewoon in moeten zitten. Bij het schrijven van een stripe wordt er parity berekend en wordt de boel weggeschreven. Als bij het weer inlezen van die stripe er data corrupted is dan zou ie dat moeten herkennen omdat ie dan als het goed is ook weer de parity controleert. Klopt de boel dan niet meer dan kan het systeem aan de hand van de data+parity de originele data weer recontstrueren. (Er kan dus normaal gesproken nooit parity berekend worden over corrupte data, omdat ie de parity al berekend voordat de boel op de (al dan niet beschadigde) schijven geschreven wordt)

[MisterE]

SambalBij schreef op woensdag 19 september 2007 @ 00:25:
Bij een RAID5 array zou die controle er gewoon in moeten zitten. Bij het schrijven van een stripe wordt er parity berekend en wordt de boel weggeschreven. Als bij het weer inlezen van die stripe er data corrupted is dan zou ie dat moeten herkennen omdat ie dan als het goed is ook weer de parity controleert. Klopt de boel dan niet meer dan kan het systeem aan de hand van de data+parity de originele data weer recontstrueren. (Er kan dus normaal gesproken nooit parity berekend worden over corrupte data, omdat ie de parity al berekend voordat de boel op de (al dan niet beschadigde) schijven geschreven wordt)

Kan je dit "bewijzen"? Waarom zou ie als alle schijven "in orde" zijn de parity blocks ook nog gebruiken? Dit kan je beschouwen als overbodige IO actie en CPU actie.
Ik weet niet of ie altijd de data van alledrie (ik ga uit van een raid5 van 3 schijven) leest of dat er een slimmer mechanisme achter zit die weet waar de data staat en waar de parity meuk.

Niet dat ik het erg zou vinden als ie de boel nog eens controleert via de parity. Dataveiligheid boven alles

[SambalBij]

Het was een beetje een aanname van mijn kant.
Voor zover ik nu kan vinden berekend ie bij het lezen inderdaad niet opnieuw de parity, tenzij er bij het lezen van een van de blokken data crc errors optreden. In dat geval gaat ie met behulp van de parity de originele data opnieuw berekenen.

Volgens Wikipedia:

The parity blocks are not read on data reads, since this would be unnecessary overhead and would diminish performance. The parity blocks are read, however, when a read of a data sector results in a cyclic redundancy check (CRC) error. In this case, the sector in the same relative position within each of the remaining data blocks in the stripe and within the parity block in the stripe are used to reconstruct the errant sector. The CRC error is thus hidden from the main computer. Likewise, should a disk fail in the array, the parity blocks from the surviving disks are combined mathematically with the data blocks from the surviving disks to reconstruct the data on the failed drive "on the fly".

My bad, sorry

Maar anyway, als de data op een van de schijven niet correct is weggeschreven (en dus een crc error oplevert bij het weer inlezen) dan zou ie dus wél de parity moeten gebruiken en zou de data te reconstrueren moeten zijn. Weet niet wat ie daarna doet. Het zou in ieder geval wel gelogged moeten worden en mogelijk gooit ie bij teveel fouten of kritieke fouten een van de schijven uit de array (schijf defunct, array wordt critical en mag niet nóg een schijf verliezen)

[u_nix_we_all]

Op zich is het wel vreemd dat die badblocks test geen resultaat geeft in de normale -n mode. Verandert de lijst met bad blocks ook als je het 2x uitvoert ?

En hoe zit het eigenlijk met de automatische relocatie van badblocks door de harddisk zelf ? Dat zou je volgens mij met S.M.A.R.T moeten kunnen uitlezen ?

[MisterE]

Aangezien de parity verdeeld is over de schijven lijkt het me dus lastig te bepalen welke schijf nou de bad sector zou hebben. Maar ik lees in je quote ook iets over dat ie andere sectoren weer gebruikt om te repareren (en dus lijkt me wel te bepalen welke defect is?)

Ik zal morgen iig weer eens zo'n bad sector HD erin hangen en wat testjes doen.
ps: smart tools had ik nog niet geinstalleerd staan. Ten tweede zijn het oude schijven die bijna niets van smart ondersteunen