Inlägg

Förmodligen filer som under kopiering brutits eller hindrats på annat sätt att slutföras eller att disken kopplats ur innan all metadata är uppdaterat.

Detta är typisk OS och filsystemsrelaterat och inte att disken inte kan läsa data. För är det läsproblem för att disken börja bli gisten så är det i form av olika IO-fel.

Finns SD-media inblandat så kan det vara kameran som misslyckats i skrivning mot mediat vid tex. kyla (typiskt bit under 10 grader C) eller andra skriv/läsfel och filerna är just bara 0 byte stora som resultat. SD-media har ingen felrättning som är värd namnet och blockerar heller inte (dvs. ger IO-fel) när man börja läsa ut korrupt data.

Flashminne som USB-stickor och SD-minne fungerar inte bra i kyla om de inte förvärms innan med tex. att vara strömsatta (och regulatorn i lagringen värme upp det hela en bit) - vilket kan ge problem i produkter som stänger av lagring strömmässigt när det inte är just under användning i avsikt att spara batterier. - vi har mätinstrument som gör detta och det är ett skit att hantera detta i kyligt väder att hela tiden ta ur lagringen och ha i fickorna för att hålla värmen på dessa...

Om platsen där batteriet sitter inte blir varmare än 60 grader C under långa tider så är det inget problem att sätta en CR2032 IMHO.

Om hållbarheten blir kortare av värmen och är inte komplicerat eller krångligt att byta - byt oftare när det behövs...

Man får också skilja på batterityper när det gäller läckbenägenhet över tiden. Akali och Silveroxid-knappbatterier kan börja läcka, men under alla åren som jag sett och hanterat CR2032 och motsvarande andra storlekar av Lithium-batterier så tror jag aldrig sett någon läcka med resulterande korrosion på utsidan av batteriet oavsett hur urladdade de än är

- det är dessutom vattenfritt och rätt flyktig organisk eterliknande elektrolyt i dessa, så om de går hål i sig så blir de snart torra invändigt och inte vandring av salter på samma sätt som med batterier med vattenbaserad kaliumhydroxid-baserad hygroskopisk elektrolyt (som de tjockare och smalare knappceller som silveroxidbatterier liknande SR44 och motsvarande samt akali-batterier)

Hållbarhet och värmetåligheten är till stor del bestämd av packningen/förseglingens material och utförande mellan batteriets plåthalvor och hur bra de håller kvar den flyktiga elektrolyten över tid och bestämmer hur länge de håller vid olika temperaturer.

För snurrdiskar har man ofta många chanser att rädda data hyffsat oskadat från att de börja gnälla på SMART eller upplevs slöa, tills det är för sent, ja, ibland flera år på sig... - medans havererande SSD/NVMe så är det ofta lika plötsligt död som en skärmsläckare släcker skärmen och det blir svart utan någon som helst förvarning - det är bara att gilla läget när det gäller SSD/NVMe:s katastrofala haveri-beteenden - för den är inte bra...

Kolla om disken är läsbar på RAW-mode under en Linux och helt enkelt ta ut en diskimage från denna med lämpligt program (i Linux används 'ddrescue' eller om man är mer van - 'dd') eller med tex. clonezilla och dussintals andra ofta kommersiella diskkloningsprogram under windows - detta _innan_ du gör några 'diskräddningsoperationer' med något program

med diskimage sparad så kan du alltid återställa disken till hur den såg ut innan du provade med några diskreparationsprogram om dessa misslyckas och det blivit mess av det.

Är den inte läsbar alls eller inte är synlig i BIOS längre som en lagringsenhet så är det i regel för dyr för dig som privat/konsument att skicka denna till en diskräddare då att rädda data ur SSD/NVMe är _mycket_ dyrare än att rädda data från en havererad snurrdisk. - är det inte kända standardfel så kanske diskräddningsföretagen nekar att ta sig an din lagring då det inte går att få fram data till rimlig insats för dem till ett pris som de tror att du är villig att betala för.

---

slutligen - nu vet du varför man behöver göra regelbundna backupper... och diskarna som gick åt till dina räddningsoperationer innan, kan du nu ha som backupmedia...

Redan 16 tecken och symboler är besvärligt nog - men under förutsättning att de _är_ slumpmässigt framtagna!.

16 tecken av urval av 94 symboler (alla skrivbara tecken i ASCII-7bit utom mellanslag) ger med 94¹⁶ = 3.7157429e+31 och med ln(3.7157429e+31) / ln(2) = 104.9 bit entropi

Man skall vara väldig angelägen och ha enormt tålamod samt väldigt stor maskin och energibudget för att knäcka det till ens 50% halvvägs...

Är tveksamt att någon ens till idag har lyckats knäckt med brute force en lösen med 80 bitars entropi... när man bevisligen med mycket möda knäckte SHA1-hash så visade den sig inte ha mer än runt 63 bit i praktisk entropi och då var det månaders beräkningar med googels infrastrukur av stora mängder datorer var gång man fick träff/knäck.

Kolla att SATA-portar typisk 5 och 6 inte har plockat bort anslutning till din m.2_3 - brukar vara ganska typiskt att den sista M.2-porten och de högsta SATA-portar delar samma PCIe-linor och du kan bara ha det ena eller andra - inte båda samtidigt. kolla i BIOS om detta. att den andre M.2-porten är gen-3 kan förklaras av att den är redan gått igenom en chip som skapat fler PCIe-lines och som kan växla mellan SATA och PCIe medans m.2_1 i Gen-4 är direktansluten till din CPU

Windows kan bara starta på SATA-diskar och presenterar lagringen sig som något annat som virtuella volymer från en RAID eller en SCSI-disk så kan inte windows boota hur mycket du än försöker utan stöd i BIOS eller extra drivrutiner, som i princip wrappar lagringen och presenterar den som en SATA-disk - då all dataöverföring sker ändå med SCSI-kommandon oavsett SATA eller SCSI-disk.

NVMe behöver också en emuleringslager till SCSI-kommandon men är oftast redan konverterad i BIOS eller drivrutin i använda OS då all logisk hantering är i form av SCSI-kommandon från OS sett och är inget som enkelt kan bytas till något annat oavsett om det är Linux eller Windows.

Vill du sätta hela företagets existens som insats så använd en molnlösning - vill du att företaget skall existera även efter att molntjänstföretaget har gjort bort sig - se till att ha parallellt system eller åtminstone uppdaterade backupper och VM-images av era körande mjukvaror hos er eller lagrad på en ytterligare oberoende molntjänst som inte är samma som hostar tjänsterna - och se till att backupperna är resilenta ( att tålas att skrivas över med en krypterade version som ersätter orginalet och du skall ändå kunna får fram orginalet igen upp till x antal månader om du får en ransomware-angrepp på halsen)

Jag har sett på ganska nära håll vad som händer när man överlåter sådant till en extern tjänst och de klantade sig - företaget försökte överleva några år på olika sätt men idag finns de inte kvar...

Det är ja g och nej där - gammal media kan hålla data +10 år enkelt - en del av de över 50 år med att bara kvaliten sjunker (blir brusigare, tappar färger etc.)

idag så tappar man hela block med data när det är 1 bitfel för mycket som inte hanteras av felrättningen och lagringstiden kan vara nere i veckor/månader när felmängden nått den punkten som tex. QLC-baserade minnen förvaras varmt utan att vara strömsatta...

missade på microdrivern att den var faktiskt större än jag trodde.

jag vet hur det sved när man köpte 1.6 GB-disken från Miniscribe (SCSI-disk) och tyckte att den var enormt stor gentemot vad alla andra hade i samtiden...

Det är historiskt sett från flygtransporter/flygfrakt för att bedöma mängden aktiv lithium i batteriet när det räknas som en enda cell oavsett om de i verkligheten är både serie och parallellkopplade som i många av dagens laptop-batterier och det kommer främst från tiden när lithiumbatterier ofta var primärceller

Mängden lithium och antalet (m)Ah är nämligen väldigt hårt kopplat medans antalet Wh kan variera med olika katod och anodmaterial och om det är primär (engångs) eller sekundärcell (laddningsbart) för samma mängd lithium, och eftersom sekundärcellerna har mer energi av sin högre polspänning så har man också en Wh-begränsning. och det är mängden lithium och mängden energi - vilket som kommer först som bestämmer om en batteripack fås tas med på flyget eller inte

I linux spelar inte den fysiskt inkopplade ordningsföljden någon roll med sina egna mjukvaruraid (mdadm-RAID, LVM, LVM2, ZFS, BTRFS) då alla ingående partitioner kan identifileras med UUID och under UUID och det fins lista/struktur som säger vilken ordning och ordningsföljd de hänger ihop mot varandra.

HW-raid har inte något sådant utan på sin höjd berättar headen på disken allra första block i hur stripingen är mellan enheterna och vilken RAID-mode som används, men inte hur diskarna är inordnade gentemot varandra rent logiskt - det blir alltså väldigt fel om man byter fysisk plats på två diskar i en HW-RAID-struktur.

2 MB-storleken som HD-3.5" disketterna märks med är är i storleken i RAW-format - dvs. baserat på hur många tydliga fältväxlingar som får plats på ett varv och detta gånger 80 gånger 2 för diskens fulla kapacitet på 2MB

En sektor på disketten har en antal fält för sektoradressering, checksummor, synkningsbittåg och en eller flera GAP för att hantera glappet och tidsvariationerna som blir när man växlar från läsning (för att identifiera rätt sektor) till skrivning precis när man precis passerat sektohuvudet och dess fält och det kan hoppa fram och tillbaka en smula av timing-missar från CPU när själva datasektorn börja skrivas - detta med 'GAP' och GAP3 finns också på hårddiskars sektorer där man har samma problem med när läsning av metadata för sektorn skall övergå i skrivning precis efter...

Det vanligaste sättet att öka lagringsstorleken på en disketter var att helt enkelt att göra mycket längre/större sektorer så att overheaden av ovan nämnda sektorindelning och sektoradressering blev mindre relativt mängden data. i somliga format hade man bara en sektor per varv.

Nackdelen är förstås att risken för oupptäckta fel ökar då använda checksumma kan bara till 100% upptäcka ett visst antal samtidiga bitfel upp till en viss storlek (typiskt upp till 4 bitar fel samtidigt för en 512-bytes sektor) ) och ju större sektorn ju färre bitar fel kan den upptäcka på säkert sätt att det är felaktig och vid ännu större sektorer fins det möjliga felaktiga kombinationer som ger samma checksumma som en korrekt sektor och i princip har felkontrollen degraderats så lågt att den bara kan detektera udda antal bitfel medans jämna antal bitfel kan missas. På disketter har man ingen felrättade kod utan bara checksumma som anger fel och få logiken att prova att läsa om samma sektor ett flertal gången och hoppas att någon av läsningarna är korrekt (sedd till checksumman...)

Om det är LSI-baserade HBA/smartcontrollers så har jag för mig att mdadm-RAID hade moder som kunde förstå headarna i början på var disk (när de läses i IT-mode) och sätta ihop en raid från en trasig HW-RAID kontroller - dock är det inte lika bekvämt som med mjukvaruraid där man kan montera in diskarna i valfri ordningsföljd och även via olika gränssnitt (usb, sata eller sas) blandat, utan där är det strikt rätt ordningsföljd sett rent logiskt mellan diskarna som gäller - det är väldigt lämpligt att göra diskimage av var disk (med HBA i IT-mode) innan man försöker fösa ihop dessa till en RAID-struktur av diskar som kommer ifrån på en (trasig) HW-RAID.

Det kommer med stor sannolikhet bli helt fel vid första försöket och följden en skrotad RAID-struktur eftersom räkneordningen av diskarna är inte självklar (och ofta spegelvänd sedd till fysisk placering gentemot logisk ordningsföljd sedd framifrån - dvs. räknas från höger till vänster och i grupper om fyra diskar liknande 4,3,2,1,8,7,6,5) och ytterligare andra mönster om diskarna ligger i två våningsplan.

Man kan bli förvirrad för mindre och det är extremt kritiskt att ordningsföljden är rätt logiskt sett när det kopplas till en Smartkontroller (HW-RAID) som P400, P410, P420 (HPE), PERC5, PERC6 (Dell) etc. då det inte sorterar ut det själv och blir det fel ordning så får man seriös RAID-haveri.

$MFT är en systemfil som alltid växer och aldrig krymper igen och tillväxtakten är ca 1 GB per 1 miljon filer och storleken sätts av hur många filer man har haft i filsystemet samtidigt under hittillsvarande livstid för filsystemet.

Är NTFS formaterad med flaggan /V för att tåla fragmenterade filer med större antal fragment när filer växer för att de hela tiden sakta fylls på med data (som loggfiler eller mappar där det hela tiden fylls på med småfiler som thumbnails av bildarkiv - då även själva mappen (som är en specialfil i filsystemet som hanteras i $MFT på samma sätt som alla andra filer) också blir fragmenterad och defragmenteras normalt inte av MS egna defragmenteringsprogram som körs då och då (typiskt 1 ggr i veckan) och en dag helt plötsligt går det inte att lägga i fler filer i mappen...), så växer $MFT med 4 GB per 1 miljon filer då minsta entryt för en fil är då 4 Kbyte istället 1 Kbyte.

Enda sättet att få bort en stor och svulstig och i en del fall kraftigt fragmenterad $MFT är att sonika formatera om hela lagringen.

---

Som utvikning så måste något vara rejält trasigt prestandamässigt i en nyligen uppdaterad win10 när man kör mot en extern 4TB/5/TB 2.5" USB-snurrdisk av SMR-typ - tänk typisk fall när man vill göra backupper av en systemdisk fil för fil till en långtidslagringstålig snurrdisk.

När man i linux kopierar in från en lite lagom halvmogen windowspartitions root-mapparna som "Programdata, Program Files, Program Files (x86) och Windows" på en NVMe disk till en till ovan nämnda snurrdisk(ar) av SMR-typ till en BTRFS-volym under Linux så tar det 7:56 minute och med komprimerad mapp i BTRFS, 8:16 minuter och mot en likadan disk med NTFS formaterat tog det 9:36 minuter med linux använda kernelbaserade NTFS-stöd.

Det var i detta fall 602369 filer och mappar fördelat på 417989 filer och 184380 mappar och knappt 47 GB i total storlek (ja det ligger väldigt många småfiler och mappar i olika djupa mappträn i dessa mappar varav en stor del är hårdlänkade mot varandra - därför testen med just dessa mappar mot SMR-diskar för att stressa denna)

Därefter tänkte jag köra samma operation i Windows - och det tog tvärstopp och segt som frusen sirap och det började komma en massa varningar om låsta filer mm., bröt det och tänkte att jag kopierar först över dessa ovan nämnda mapp med kopierade systemmappar som fanns på snurrdisken till en mapp på NVMe-lagringen på systemdisken - och sedan köra tillbaka dessa mot SMR-snurrdisken på en ny mapp och se hur fort det gick.

Att kopiera från snurrdisken till NVMe där SMR inte borde ha någon större effekt - gick också segt som sirap och överföringen tog 168 minuter - viss skillnad mot runt 8 minute när det gjordes med linux...

Så varför gick det långsam - tittade i windows 'performance center' medans kopieringen pågick och där det stallade på hela tiden var att att en massa data på $MFT och $LOG skrevs konstant och en del $Bitmap baklänges mot disken fast den egentligen bara skulle läsa från disken - dvs. rev om filsystemets metadata konstant hela tiden med stora mängder skriven data och det körde förstås slut på SMR-diskens PMR-del ganska fort och det var långa perioder det bara skrev data på disken utan att det kopierad något från disken till NVMe-lagringen - på en disk det egentligen bara skulle läsa data ifrån... pausade jag kopieringen så slutade det också att skriva mot disken efter en ganska lång stund, startade jag igen så började det skriva igen mot $MFT och $LOG - så det var ingen bakgrundsindexering av filer av vad jag kunde se...

Tillbakaskrivningen av mapparna som kopierades in innan från NVMe-disken till SMR-disken är ännu inte fullt genomförd då jag inte orkade att vänta på att den skulle bli klar, men efter 86 minuter så hade det hunnit överföra 26014 filer varav 2292 mappar 23722 filer med total storlek av 5241 Mbyte. - med den takten hade det tagit hela dagen att få över dessa 47 GB med data till SMR-snurrdisken...

Kopieringen gjordes med 'time cp -ra X Y ' i båda fallen för att få körtider när det blev slutfört och i windows då under 'gitbash', men kollade innan med total commander och file-explorern där det var mycket tydligt att kopieringen inte gick speciellt fort där heller.

Detta kan inte förklaras med att NTFS är generellt urusel efter som paragons NTFS-implementation i Linux-kärnan faktiskt skrev filerna rätt fort och uppenbarligen i en skrivordning som inte helt tömde SMR-disken PMR-area vid 47 GB total skrivvolym.

Det ser ut som att det är windows själv som har en massa hyss för sig med för många mellanlager från den abstraktionslagren programmet ser när den öppnar, skriver och stänger filer till att det når ned till att skriva fysisk på diskytan/flashblocken

Och en del i detta är den vansinnigt stora mängd med metadata som inflätat med datat skrivs mot lagringen hela tiden - där SSD/NVMe snabba sökning döljer en stor del av detta när det skriver fram och tillbaka på olika delar av $MFT, $LOG och $BITMAP (och var modifiering där måste uppdateras i $MFT igen eftersom dessa är självrefererande) men på magnetisk lagringsmedia blir en svår och tidsfördröjande belastning av de många sökningarna på olika platser hela tiden.

Undrar om VSS (Shadow copy) och defender i from av mellanlager mellan applikationen och fysiska lagringen är en del av problemet varför det är så kostsamt tidmässigt nu att skriva till en mekanisk disk under win10...

Detta måste ha barkat i helt galen väg med skrivstrategier och cachning mot lagring, för så tungdrivet var det inte på windows på 2010-2015 talet och tidigare med winXP och win7 på mekaniska diskar...

Nu har jag inte kollat på andra windatorer för att bekräfta denna beteende men denna windows är rätt sparsamt använd och främst för spel när man väl kör windows - annars snurra bara linux på denna burk till 90% av tiden.

En av de saker man kanske missar är att för en del BIOS så måste USB-stickan sitta i USB-taget _innan_ man man slår på strömmen för att den skall scannas och upptäckas att vara en bootbar enhet - att göra en reboot ur tex. BIOS-menyerna räcker inte då det inte är samma sak som en kall/strömpåslags-start.

Det andra är att ibland sätter USB-minnes tillverkaren en lite bit fel och USB-lagringen upptäcks som 'mass storage' och inte som 'removable mass storage' vilket också kan omöjliggöra en boot och installation från stickan och det enda man kan göra är att byta USB-stickan till en annan batch eller märke och hoppas på att den är rätt markerad.

När man har strul oavsett vad man gör för att boota på USB så är ibland den enda vägen att koppla in en USB-ansluten DVD-läsare - bränna ut iso-imgen på en skiva och sedan boota på denna - och då kan fortfarande första stycket fortfarande gälla - dvs. skivan insatt i läsaren och läsaren ansluten till datorn som skall boota på mediat _innan_ man slår på strömmen till datorn...

Att du raderar filer synligt i explorern eller program betyder inte alltid att de försvinner fysiskt från disken/metadatan förrän efter en tid eller ett antal omstarter. En av mekanismerna som kan ta plats är VSS aka "Volyme Shadow Copy" som du inte ser arbetar men lagrar datablock som kan ta en del plats under "System Volume Information" och normalt inte kan inspekteras medans du kör windows (det hindrar access för att kunna se filer eller se storleken på mappen). Du har återställningspunkter - kanske versionshantering av filer i explorer samt kvarvarande filer i papperskorgen varav en del av det använder sig av VSS.

en 16 TB disk som bara har 300 - 100 GB (1-2%) ledigt utrymme kvar är att ses som väldigt full och filutläggningen över ytan när filerna skrivs blir inte lika bra och mer upphackad och ger mer sökningar än när disken är mindre fylld - speciellt på NTFS som är ökänd att lätt fragmentera filer i småbitar över diskytan.

på en systemdisk skall man helst inte fylla disken mer än till ca 80% eftersom filer i olika storlekar skrivs och raderas hela tiden medans typiska medialagringsdiskar som bara fylls på och i bara liten utsträckning ändrar inom filer och ta bort filer så kan man fylla lite mer.

Är det den uppgivna volymstorleken som blivit 200 GB mindre eller är det 200 GB mindre med ledig plats än vad som förväntas av filsystemet (dvs maxstorleken på filsystemet är samma som innan).

har du kopierat alla dina filer till en backup-disk och sett att det går att läsa dem utan fel (som io-error etc.) - det är läge att göra backup till annan fristående media oavsett när man tycker sig ha lagringsstrul.

I förstnämnda fallet så ha tex partitionmagic, gparted eller andra partitionshanterar eller motsvarande minska på filsystemet för att skapa ledig plats på lagringen för tex. en ytterligare partition.

I det andra fallet så har någon väldigt stor fil skapats i filsystemet av någon orsak och tex med användande av spacesniffer (och körs som administrator) så kan man snabbt visuellt se om någon fil tar enormt med plats i någon mapp.