Unsafe shutdowns ssd

Hur stänger du av datorn? - inte för att det hjälper nämnvärt mer att om du aldrig stänger av..

Många OS och BIOS gör fel och kollar inte eller koordinerar med SSD/NVMe om den är klar när den fimpar strömmen och då får man då och då sådana tillfällen när SSD höll på något internt just när spänningen försvann.

Du har säkert hört/läst historier varför laptopen/datorn inte startar en morron och all data är försvunnen och det skulle kosta enormt mycket för en dataräddningsfirma att få fram datat igen - och det är av just den orsaken, problemet är att det händer för sällan med fatala haverier för att någon på OS/moderkort eller tillverkarna av flashlagring på konsumentnivå skall bry sig om att göra något åt det då det till 999 av 1000 gånger inte blir något problem...

Med andra ord se till att hålla dina backupper av dina viktiga data på annan media/molnet ofta uppdaterade, det gäller i princip all lagring med flashminnen och det inte har vidtagits extra (kostsamma) steg för att undvika det.

Det fins anledning varför enterprise-versioner av SSD (SATA/SAS) har kondensatorbanker för att klara sig igenom dessa plötsliga ej koordinerade strömavbrott (och även externa USB-diskar som Samsung T7 med jättebanken kondensatorer för att det inte skall bli fel om USB-sladden glappar på strömsidan eller rycks ut plötsligt utan förvarning)

Ett enkelt tryck på powerknappen i windows är standard att göra samma sak som att gå på start->stäng av.
Hen skrev aldrig att hen höll in knappen. Men du har helt rätt att man inte ska hålla inne knappen. Men går utmärkt att stänga av med ett enkelt tryck, det skickar ett normalt "stäng av datorn" kommando till windows

Sen om man som jag har barn så kan man stänga av så knappen inte gör nånting.
Eller ändra så den försätter datorn i viloläge...men det är ju bara dumt

Man kan välja vad som ska hända när man trycker på strömbrytaren.
-Gör ingenting
-Strömsparläge
-Stäng av
-Stäng av skärmen

Intressant problem och jag funderat på hur fasen kunde det ske - både SATA och PCIe använder checksummor i sin överföring och något där borde ha reagerat tycker jag.

Nu vet jag inte vilken OS eller filsystem, men är det NTFS så fins det absolut inget alls som kan hinta om data blev felskrivet, men kör man filsystem som BTRFS och ZFS så hade problemen förmodligen upptäckts när man återläser den skrivna datat, då all data och metadata har checksumma , ext4 kanske hade reagerat på om det skulle bli fel på metadatat för filerna då de har en checksumma på den delen men inte på själva datamängden.

i windows är det bara ReFS som har möjlighet med integritetskontroll på metadata och data - om det är påslaget vill säga, ofta är det inte av prestandaskäl för de få som fortfarande använder det.

Det upptäcktes av Linux och filsystemen (BTRFS) hamnade i skrivskyddat läge. Felet försvann när jag monterade om moderkortet i nytt chassi. I alla fall enligt tester av RAM som då godkändes av memtest86 i 48 timmars test. (skrek innan konstant). Vilken typ av fel är svårt att avgöra men sista TB på alla hårddiskar var rena bajset vilket utspritt på 6 diskar med minst 3 uppsättningar så vid en återställning kunde tester garantera att 99% av filerna var intakta, förutsatt att dom inte hade exakt samma fel. Sedan finns en annan maskin med exakt samma innehåll också. Man fick blåsa diskarna så man var säker på att innehållet var rent.

Litar dock inte på det moderkortet längre, i alla fall inte skarpt.

Jag har haft minnesfel som har åstadkommit den typen av problem - dvs. fel som kunnat hittas med memtest86 - en del konstanta, andra fladdrar då och då, och det var samma här att det var BTRFS vid läsning som sa ifrån, som hintade om att det var ett bekymmer.

Skadade bara ett fåtal filer av backuptyp så ingen skada skedd, men utan detta så hade det kunna pågå lång tid utan att man förstått att filerna skadats och fått korruption under skrivning - typ först när man återläste komprimerade filer och det stanna halvvägs igenom med CRC-fel inom arkivet - då de klassiska filsystemen har ingen upptäcktsförmåga alls när sådant sker.

Läxan av det är när man har man lagring av mer känslig slag så kör man det på servrar som använder ECC-minne, då jag tror att inte ens ZFS klarar sig helskinnat om själva ramminnet börja krångla, men det viktiga med dessa filsystem (ZFS, BTRFS) är att de börja skrika när det blir fel, dock inte medans datat skrivs, utan först senare när det läses. Så är det kritiskt så bör man också köra en 'scrub' ganska ofta för att just läsa strukturerna och finna de som inte längre stämmer överens med sektorinnehållet och dess checksumma. Det är också hemska fel då om de tex. synkas mot molntjänst så blir filerna i molntjänsten också pajade.

Med din beskrivning tror jag huvudproblemet för dig inte var överföringarna mot diskarna som var problemet - utan att dina ramminnen började paja och korrupera datat medans du skrev den trasig TB-delen av filerna.

Hade det varit överföringsstrul på SATA/PCIe-snörena så hade du förmodligen fått reda på det, och om felet hade passerat obemärkt i överföringen så pratar vi om 1-2 bitfel per år vid kontinuerlig körning på max fart över SATA-bussen med den CRC32 som används där, med CRC32C som polynom som tex. SAS-bussen använder så tar det 1000 gånger längre tid mellan tillfällena, förmodligen något liknande på PCIe-bussen (har inte koll på vilken CRC-checksummepolynom eller hur många bit de använder där).

Metadatat på ext4, all data på BTRFS och CRC på SAS-bussen använder CRC32C som checksumma-polynom, medans ZFS har länge använt (vet inte vad som är default idag, men förhoppningsvis något annat än) fletcher som algoritm, vilket är helt hål i huvudet om avsikten var att fånga fel som missas av CRC32 som används av SATA-bussen.

Som analogi med checksummealgoritm som ett filterpapper som fångar skräp i ett flöde är CRC32 som ett kaffefilter i att fånga små partiklar, medans fletcher är ett glest fisknät - medans CRC32C är filter i klass för renrum inom IC-tillverkning... fletcher kan ju teoretiskt fånga ett fel som CRC32 i SATA-bussen missar, men då blir det att vänta lääääääänge...