SSD's in Raid 0 Series 7 Voor Trim en Low error level Handling

Door BitBooster op dinsdag 09 juli 2013 01:41 - Reacties (8)
Categorie: -, Views: 2.797

Op Series 7 moederborden is vanaf intel IRST option rom 11.5 mogelijk om in Raid 0 met SSD's om over Trim fuctionaliteit te beschikken. De option rom is zelf in je bios te modden indien je over een eerder niet compatible versie beschikt. Voor series 6 zijn er zelfs enkele mods beschikbaar. Hier is veel achtergrondinfo op het internet over te vinden waar ik nu verder niet naar ga verwijzen.

De roms en de instructies voor het updaten van je bios naar zijn te vinden op: http://www.win-lite.de/wb...odding-already-extracted/

Ik heb een vraag naar aanleiding over onduidelijkhededen m.b.t. de low level bios implementaie aangaande bad media block / reallocation in raid 0 SSD's

Ik ben in het bezit van een P8Z77V_PROTHUNDERBOLT/ moederbord welke voldoet aan de mogelijkheid om Raid en Trim in te schakelen onder windows 8 (en 7). Ik heb mijn option rom in de bios wel moeten updaten om compatible te zijn met Trim voor SSD's in Raid 0 en draai de laatste windows IRST drivers. Trim werkt naar behoren!!. Het werkt zelfs zo fantastisch met mijn 2 OCZ vector SSD's dat ik een sequentiele doorvoer van boven de 1 Gigabyte per seconde!!

Echter ik heb één bad media block / sector reallocation gehad waarna mijn systeem en de bijbehorende backup die ik had gemaakt corrupt werden. Ik kon zelfs met Acronis TI Home mijn backup niet meer terugzetten. Mijn Windows log liep vol en ik heb de Raid config moeten herinitialiseren, formatteren en een vorige backup terug moeten zetten.

Diskinfo (Crystal) gaf aan dat 1 van de SSD's één reallocated block had gekregen.

Mijn vraag aan OCZ was of dit niet transparant low level afgehandeld zou moeten worden door de bios of de desbetreffende drive / firmware.

Niemand, ook niet 2e lijns support en doorverwezen specialisten wisten uberhaupt een antwoord hierover te geven.

Heeft iemand hier ervaring mee want ik zit met angst te wachten op de volgende sector reallocation waarbij mijn systeem weer compleet corrupt wordt.

Reacties


Door Tweakers user CiPHER, dinsdag 09 juli 2013 07:04

Een tweakblog is wellicht niet de meest handige plek om dit soort vragen te stellen. Maar vooruit. :P

Maar je dient wel voldoende informatie te geven in de vorm van de SMART gegevens. Als het om een reallocated sector (page) gaat, dan is dat niet veel bijzonders. De host zal na de herlocatie geen problemen mogen ondervinden omdat de sector of page is omgewisseld. Dit betekent dat dat alle sectoren op je SSD gewoon leesbaar en schrijfbaar zijn.

Ik begrijp verder ook niet zo wat het in RAID0 plaatsen van twee SSDs hiermee te maken heeft?! Voor de SSD zelf maakt dat niet uit; weet die veel wat jij ermee doet in combinatie met andere SSDs. De individuele SSD krijgt gewoon read en writerequests en is zich niet bewust van RAID op host-niveau.

Door BitBooster, dinsdag 09 juli 2013 07:30

@CiPherOm: om te beginnen excuses dan maar waar had ik deze post dan moeten plaatsen? Het is mijn eerste tweakblog. Wat is de gangbare strekking van een tweakblog dan?

Het is ook ter informatie voor het plaatsen van SSD's in Raid met behoud van Trim.

Ik snap echter niet waardoor mijn systeem bij een realloc sector meteen corrupt werd. Vraag is dan ook meteen wat kan de oorzaak dan zijn in bovengenoemde configuratie. Ik ging er ook vanuit dat een bad sector / herlocatie geen probleem had mogen veroorzaken..

Door Tweakers user CiPHER, dinsdag 09 juli 2013 07:45

Je gaat er ook vanuit dat de problemen die je hebt ondervonden te wijten zijn aan een reallocated sector. Dat vind ik zelf erg onaannemelijk. Veel logischer zou zijn dat je simpelweg andere problemen hebt gehad met één van je SSDs. Aangezien je SSDs van het merk OCZ hebt, is dat ook niet zo vergezocht. Al weet ik niet zo heel veel over het type dat jij hebt - de Vector.

Als je de problemen ook hebt nadat de page is omgewisseld, zoals je kunt zien in de SMART gegevens, dan kan dat simpelweg niet de oorzaak zijn.

Tweakblogs zijn normaliter bestemd om zelf een verhaaltje te schrijven, niet om technisch advies in te winnen daarvoor hebben we het forum. In jouw geval zou je voor dit soort vragen het Opslagtechnologie forum kunnen raadplegen.

Door BitBooster, dinsdag 09 juli 2013 16:46

@Cipher: Gheh, ik heb meteen niet de minste te pakken die mij een reactie geeft ;). Ik heb even stiekem gekeken naar jouw rep. op Tweakers. Complimenten voor je artikelen o.a. rondom SSD's en andere harde waren!!

Tsjah, het is wel stom toeval dat beide SMART results allemaal schoon van reallocs waren. Drives waren alle vlekkeloos en na dat incident meteen een een drive een realloc had.

Maar nog even om van je ervaring gebruik te maken: De onderstelling die ik had is toch juist dan dat de drives an sich ook al staan ze in raid niet in sync moeten zijn qua (striped aligned) sectoren?? Want daar ging ik dan vanuit dat dit door de realloc een probleem had veroorzaakt.

Ik ben voor de Vector serie gegaan omdat deze nieuw waren bij OCZ, volop de hemel in werden geprezen (door OCZ) en ik moet zeggen de thoughput is bijzonder goed n.l. 1088 MB/sec voor de 2 512's in Raid 0. Destijds een aankoop van 1300 euro voor 2x 512 GB en 1x 256. Ik was in de veronderstelling om toch geen kat in de zak te kopen. Maar was niet op de hoogte van de (vroegere) reputatie van hun schijfjes. Ik ben er anders wel over te spreken. Ik zou graag eens een niet partijdige review zien waarin de Vector serie degelijk onder de loep wordt genomen zonder vooroordelen.

Door Tweakers user CiPHER, dinsdag 09 juli 2013 17:58

Tsjah, het is wel stom toeval dat beide SMART results allemaal schoon van reallocs waren. Drives waren alle vlekkeloos en na dat incident meteen een een drive een realloc had.
Als je vóór het incident een schone SMART had en direct na het incident er een reallocated sector was, dan is het opeens wel weer aannemelijk dat je een bad sector probleem had. Het punt is dat gedurende het 'incident' je een onleesbare page had wat problemen kan geven. Bij hardeschijven zie je dit als Current Pending Sector in de SMART-output. Na het omwisselen wordt die Reallocated Sector Count. Na het omwisselen kan de kapotte sector geen problemen meer geven, maar een actieve bad sector (Current Pending Sector) dus wel.

Kortom, het is prima mogelijk dat je wel degelijk problemen hebt gehad met een onleesbare sector/page. Maar nu deze is omgewisseld zou je hiervan geen problemen meer mogen ondervinden.
De onderstelling die ik had is toch juist dan dat de drives an sich ook al staan ze in raid niet in sync moeten zijn qua (striped aligned) sectoren?
Ik snap je niet helemaal; wat bedoel je hier precies mee? Wat bedoel je met 'in sync zijn'?
Ik ben voor de Vector serie gegaan omdat deze nieuw waren bij OCZ, volop de hemel in werden geprezen (door OCZ)
Wij van WC-eend bevelen aan: WD-eend. :P

Vector is inderdaad een heel snelle SSD. Het is alleen hopen dat je geen problemen ondervindt. OCZ is wel aantoonbaar vaker defect dan andere merken en ook firmwarebugs komen vaker voor. Maar de snelheden zijn prima dus als je geen problemen ondervindt dan zie ik niet zo'n groot probleem. Houd wel de firmwareupdates in de gaten, en zorg gewoon voor goede backups zodat het ook niet zo'n ramp is als je SSD (array) een keer crasht. Een SSD backuppen is doorgaans prima te doen doordat deze een minder opslagruimte hebben dan een hardeschijf.

Door BitBooster, woensdag 10 juli 2013 06:44

Nee, problemen heb ik niet meer. Na een herinitialisatie van de raid (in de bios) en een cleane format is de drive-array weer integer. Sectoren die gerealloceerd zijn vormen dan geen probleem meer. Maar dat was ook mijn vraag aan de heren van OCZ: Moet ik in de toekomt bij elke sector die als bad wordt aangevinkt en vervolgens wordt verplaatst rekening houden met verlies van informatie of wordt dit realtime afgevangen door de firmware. Ik blijf braaf backups maken.

En voor mensen die een trim-test willen doen: een (programma) dat na een tijd de geschreven sectoren test op lege data voldoet niet. Het blijkt vaak dat de sectoren gewoon nog data bevatten maar deze data is niet de oorspronkelijke. De te verwachten lege ruimte is dan weer herbruikt voor andere data. Ik heb de drive array sinds eind vorig jaar in gebruik en er is nog steeds geen sprake van afname in snelheid.

Door Tweakers user CiPHER, woensdag 10 juli 2013 12:33

En voor mensen die een trim-test willen doen: een (programma) dat na een tijd de geschreven sectoren test op lege data voldoet niet. Het blijkt vaak dat de sectoren gewoon nog data bevatten maar deze data is niet de oorspronkelijke. De te verwachten lege ruimte is dan weer herbruikt voor andere data.
Dat klopt maar klopt ook weer niet. Het kan inderdaad zijn dat je SSD ruimte in gebruik heeft waar jij niets naartoe hebt geschreven. Echter, als je die locaties opvraagt door ze te lezen, krijg je doodleuk nullen terug. Er wordt in dit geval geeneens van de NAND gelezen.

Dit principe wordt write remapping genoemd. Je SSD controller weet waar jij data hebt staan. Als je een gebied gaat lezen waarvan de SSD weet dat jij daar nooit iets hebt geschreven, dan stuurt het gelijk nullen terug zonder van de NAND te lezen.

Door BitBooster, zaterdag 20 juli 2013 05:55

Dit is dus niet wat ik zie. Ik zie telkens een sector met data die is te herleiden naar van (vorige) installaties. Ik gebruik de helft van mijn SSD ruimte als snelle backup van mijn systeem(en). Hieronder zit ook OSX data welke ik regelmatig dan plots zag verschijnen na een bepaalde tijd (meestal een half uur en deze staat niet 'live' op de array.

Trimmen herleidde niet automatisch naar (bovengenoemde) nullen.

De enige verklaring na lang overwegen is dat ik data te zien krijg van sectoren die niet meer in gebruik zijn en verzameld zijn door automatische garbage collection. Dit vermoeden wordt versterkt doordat ik geregeld data uit oude backups te zien krijg van (OSX) systemen die anders niet op deze disk zouden staan.

Reageren is niet meer mogelijk