Achterhalen identiteit Patriot Burst 1.92TB schijfjes.

[rewolff3]

Ik heb een RAID5 van SSD 3 disks met 1 hot spare. Totdat er 1 kapot ging en de hot spare ingebruik genomen werd. Nu is er nog 1 stuk en moet ik ECHT eens nieuwe disks gaan installeren. Disks gekocht, ding open geschroefd.

Disk met Serienummer PBEEDCB22102900272 is stuk en moet er uit. (via smartctl -i gevonden).
Probleem is een beetje dat ik dit serienummer niet op de disk kan vinden. Wel andere per-disk unieke nummers maar nergens id /dat/ serienummer te herleiden.

Random disks er uit trekken.... daar ben ik niet voor: Worst case detecteert Linux: Nu is m'n raid stuk en dan wil ie hem niet weer opstarten. Officieel is de raid nu weer redundant, maar toch ben ik er niet blij mee.

Ik heb even geprobeerd een plaatje toetevoegen. Ik krijg dan een schermvullende streep als een cursor waar ik niets mee kan. Dat werkt even niet.

Op de schijf staat PBE192TS255SSDR 9SE00112, het typenummer van het ding. Identiek over de vier disks.
Daarnaast een streepjescode met daaronder 212211115000130 . Hoe ik dat "omreken" naar de PBEEDCB22102900272 serienummers is dus mijn vraag.

...
Gebruikte software: Linux en "mdadm" en "smartctl".
...

De smartctl serienummers eindigen op 00258, 00272, 00004 en 1118424.
De opgedrukte nummers eindigen op: 00234, 000024, 000130, en 000019.

De nummers buitenop zouden een datum kunnen bevatten. Ik zou de eerste drie dan een dag of 20 na productie hebben gekocht. Zou net kunnen. De vierde heb ik 6 maanden later gekocht en zou 1 maand later geproduceerd kunnen zijn. Raar dat er zoveel verschil is, maar goed.

Het serienummer volgens smartctl zou ook een datum in kunnen zitten.... ongeveer 20 dagen eerder. Dat zou betekenen dat ik ondertussen 1 "herken". Dat beide serienummers ruimte voor honderdduizend exemplaren per dag hebben zou kunnen en mijn "sample" hint er naar dat ze er een paar honder per dag produceren. De data buitenop zouden dan een vrijdag en een donderdag zijn. De data die smartctl zou vinden zijn een zaterdag en een vrijdag.

Ik zou kunnen gokken dat in de 20 dagen tussen vermoedelijke productie van de PCB en de vermoedelijke datum van "in de behuizing stoppen" de boel niet door mekaar is geraakt. Maar het lijkt me zeer goed mogelijk dat een volgende productie stap een batch van X van die dingen in omgekeerde volgorde verwerkt dan dat ze uit de vorige stap gekomen zijn.
...

[Juup]

Je probleem is dus dat je niet weet welke van de 4 disks echt kapot is?
Out-of-the-box denkend: kijk (bij voorkeur met een warmtebeeldcamera) of 1 disk veel kouder is dan de anderen of 1 disk een rare hotspot heeft.
Kan je ook met je vingers proberen te voelen.

[dcm360]

Er valt op zich een gok te nemen, en dat is dat de schijven op dezelfde volgorde in Linux verschijnen in /dev/disk/by-path/ (daar staan allemaal symlinks in, met ls -la wordt dat vertaald naar sda, sdb, etc) als dat ze fysiek aangesloten zijn. In dat geval is het vanaf de controller de juiste aansluiting volgen naar de SSD.

[ Voor 14% gewijzigd door dcm360 op 11-11-2024 18:03 ]

[Ben(V)]

Je kunt dit commando op de commandline proberen:

sudo lshw -class disk | grep serial

Als dat niet werkt omdat lshw niet op je systeem aanwezig is kun je het volgende doen.
Breng die raidset down.
Haal de disken eruit en hang ze een voor een aan een Windows systeem.
Open een terminal met admin rechten.
Geef telkens het volgende commando tot je de juiste disk gevonden hebt:

Get-PhysicalDisk -Verbose

[ Voor 40% gewijzigd door Ben(V) op 11-11-2024 22:12 ]

[rewolff3]

@Juup : Ik heb een warmtebeeldcamera. Alleen niet zo mobiel: De FLIR app doet het niet op mijn telefoon. (eindelijk een compatible telefoon, doet de app het 1x na installatie en daarna niet meer totdat je de app verwijderd en opnieuw geinstalleerd hebt.. Hij zit nu met een kabel aan een Linux machine, op een plek waar ik hem nodig heb.

Maar dat gaat niets uithalen: de disks blijven koud. "niet werken" is "bad blocks" en "traag". Dat zie je niet op de warmtebeeldcamera. Evt. Zou ik kunnen kijken of "zwaar belasten" ze doen oplichten.

Ik heb zojuist (ik heb dat vast de afgelopen 25 jaar al eens gedaan, maar opnieuwschrijven was sneller dan opzoeken) een programma geschreven om random over de disk een lees van 1Mbyte te doen. Op een draaiende schijf zie je een soort badkuip. De seek naar het midden is max de helft van de max-seek afstand!

1 van de nieuwe disks doet strak 3ms per blok.
De oude, werkende schijf doet iets minder strak ook 3ms.
Een kapotte disk doet er regelmatig 50, 100, 500ms over om 1Mb te lezen. Die staat nu als spare in m'n raid. Moet ik er maar eens snel uithalen.

(Terwijl er "runtime" dus twee disks "permanent" zijn uitgevallen doen ze het allemaal weer ongeveer na een reboot.).

@Ben(V) Dan krijg ik dus de serial nummers die "vanuit linux" gezien worden, maar geen relatie vertonen met de serial numbers op de buitenkant van de disks.

Ik heb geen windows systeem. (nouja, er is een embedded-windows-XP machine. Die boot direct in de single-purpose-app waar ie voor bedoeld is. Geen geenrieke windows omgeving. Airgapped) Omdat het om m'n hoofd-file-server gaat, doen al mijn Linux systemen helemaal niets als dat ding uitstaat. Beetje onhandig single-point-of-failure. Maar dus ondanks 3 disks-failures het afgelopen jaar blijft het allemaal gewoon werken totdat ik de tijd neem om hem "als ik er tegen kan" even te rebooten...

[Juup]

Ken je trouwens SpinRite?
Werkt ook (erg goed) op SSDs.

[rewolff3]

Software die alleen op DOS draait? Een "lovende recencie" uit de tijd dat een 80Gb nog actueel was? Hmmm....

Wat spinrite doet, doe ik liever met de hand. Dan heb ik controle over wat ik doe. Ik heb 20 jaar lang een datarecovery bedrijf gerund. In dat kader heb ik een klant gehad die wilde opscheppen: "kijk ik heb raid, ik kan zomaar een schijf er uittrekken en alles blijft draaien!". Tot op een dag hij te recent deze demo had gegeven en de rebuild nog niet klaar was. Kon ik het oplossen. :-)

Vandaar dat ik nogal huiverig ben om m'n werkende raid bewust een schijf uit te trekken vertrouwende dat er NIET een bad-block in de resterende disks zit.

Ik heb nu de twee nieuwe disks aangesloten. Die als spares aan de raid toegevoegd, en 1 van de oude disks met de hand op "failed" gezet. Hij is nu aan het recoveren naar een spare. Dat ging in het begin met 130Mbyte per sec. Zou sneller moeten kunnen, maar goed. Nu is dat gezakt naar 20-30Mbyte per seconde. Dan is er gewoon weer wat mis. Lijkt te hangen op de WRITES naar de nieuwe schijf.

Oh, en 1 van de gare disks is weer "permanent stuk" tot een reboot.

[ Voor 3% gewijzigd door rewolff3 op 12-11-2024 13:31 ]

[Renault]

Zou je niet zorgen voor een full backup van al je data vóórdat je disks uit gaat trekken?

[rewolff3]

Ja, ik maak dagelijks backups naar twee verschillende fysieke locaties. En nog ben ik er niet happy over.

Het leek er op dat in de bios dezelfde volgorde gold als in LInux (3x ene type, 2x andere type, 1x eerste type).
Dus ik heb de Linux boel uitgezet dan 1 lostrekken, booten, naar de bios gaan en kijken welke ik er uitgetrokken had. Dit heb ik herhaald totdat ik ze allemaal wist. De ERG kapotte disk gaat nu terug onder garantie. (met nog ongeveer 3 weken garantie op de teller). In hoeverre de andere ook stuk zijn kan ik niet echt bewijzen. Ze lijken het nu te doen.