Inlägg

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.

jo tråden är snart 14 år - frågan om det fins något mer modernt som gör samma sak då jag har liknande problem med utrustning med webbgränssnitt med massa flikar och annat att kunna dokumentera vad som ställts in i dessa som referens och installations-dokument (commission...)

BTRFS är suveränt att använda för backupper till urkopplingsbar media som USB-diskar inklusive att den är snäll mot SMR-varianter av dessa - speciellt deras kapabilitet att kunna göra oberoende snapshot (inklusive read-only) som senare kan tas bort i valfri ordning, till skillnad från ZFS. - BTRFS har komprimerande filsystem om man vill och givetvis är allt data och metadata checksummad och arbetar med COW och betydligt tåligare för 'misshandel' i form av plötsliga strömabrott/urryckta USB-kablar under full skrivning utan att filsystemet blir korrupt (har aldrig lyckas hittills) än tex. i jämförelse med NTFS (ryser, nästa vilken som helst av dagens använda filsystem i Linux är tåligare och bättre än NTFS när det gäller risk för ej dataräddningsbar korruption).

Men som nämnt är varken ZFS eller BTRFS de snabbaste filsystemet - där är ext4 och XFS de snabbare alternativen - särskilt när XFS en gång i tiden designades för att hantera ljud och videoströmmar där man inte tål stallning och/eller tappade frames vid realtidsinspelning för att lagringen var upptagen lite längre än normalt.

Och en bra backupstrategi - gäller förvissa alla serversystem men ZFS är väldigt jobbig att reparera om den skulle för sig att gå sönder. Det är ingen filsystem man försöker reparera eller rädda ur data ur den dagen den havererar - rekommendationen är att använder senaste backuppen i dessa fall...

Själv har jag kört på BTRFS länge bl.a för deras sätt att kunna göra snapshot fri och oberoende mellan generationerna och även tas bort utan restriktioner mellan generationerna - vilket det inte är i ZFS. och den har faktiskt verktyg för att läsa ur innehållet ur en kraschad image även om man precis som med ZFS inte skall förutsätta att det fungerar varje gång utan också ha backupper.

Tycker det är lite väl mycket skit på tieto...

En stor del, ja, den största delen av ansvaret ligger på dataägarna själva att inte lägga allt i samma korg utan fördela ut sin viktiga data på flera lagringar - kanske 1 exemplar tom. hos sig själva. Att tappa data på denna sätt borde hantera på samma sätt som ekonomisk förskingring och lagföras på samma sätt då data är i många fall en stor del av värdet i företagen idag!.

Köpta tjänster oavsett avtal, kan misslyckas i sin verksamhet eller företaget bakom denna hamnar på obestånd och det går i konkurs - datat som de har just då - är efter konkursens klubbning något som konkursförvaltaren kan sälja - din data alltså - din Intellektuella Property, Patent, dina källkoder, produktutveckling - din OLF-system och produktionsunderlag etc. är helt plötligt till salu till bäst betalande!!

Tydligen tänker man inte på sådana saker när man blir lockad att lägga allt, både lagring och drift på molnet och det där sådana här händelse med Tieto mfl. olika molntjänstföretags som behöver hända innan någon förnuft kanske hittar tillbaka till företagsledningarna igen - kan man hoppas...

dessa kunde man göra bulkerase med starka magneter och sedan formatera upp dessa igen - det fins ingen magnetmönster som inte gick att återskapa i en vanlig diskettdrive med formatering.

men man skall också komma ihåg att det fanns versioner med mjukare magnetmaterial och mindre lagringsstorlek även på 3.5 MB-storlek innan det blev versionen med 1.44 MB - bl.a för Apple, Amiga mfl. och dessa i fel drive kan bli problematiska - dessa 600 - 720 Kbytes disketter är idag mer eller mindre skottpengar på då i sammanhanget är sällsynta gentemot de enorma mängderna 2MB/1.44 MB-disketter som producerades i många år.