NTFS usb-disk som inte går att mounta

Inte köra chkdsk om du inte har gjort en diskimage av disken innan till en annan USB-disk som fil innan...

Det är rysk roulette med 3 patroner i sex kamrar att köra programmen - det kan sluta att det fungerar och alla nöjda, men också att du förlorar hela disken utan möjlighet att rädda något användbart...

NTFS skall man helst undvika att ha på extern USB-lagring då den är för ömtålig och gör jättehaveri redan vjd få och små fel (tex. sönderskriven huvud av $MFT och $MFT_mirr - vilket är det sista som skrivs när man stänger en NTFS-disk och det första som läses när NTFS öppnas, skrivs de sönder så är det jobbigt på riktigt och dessvärre har det funnits en del USB/SATA-ship i USB-kabinett som just gör det om USB-avstängningskommando kommer för tvärt efter som vid "safe remove" - tex. WD-book anno 2010-2015. - jag skulle säga att det är säkrare att rycka ur disken rakt av (och låta den kontrolleras vid nästa inkoppling) när den slutat att arbeta med läshuvudena än att använda 'safe remove' på just dessa serier av externa diskar...

det är så illa att jag numera betraktar "safe remove" som 'data destroyer' när det görs i windows på externa USB-diskar...

Men kör man enbart Windows-världen så fins inga bra alternativa filsystem om man inte kan få igång ReFS tyvärr.

---

i Linux-världen är ext4 och BTRFS väldigt tåliga och med journalföring (till skillnad från NTFS som gör sådana saker halvhjärtat och inkomplett, vilket har betydelse när det krånglar)

BTRFS är dessutom ett filsystem som inte skriver över gammal data, transaktionshanterande och därmed kan göra rollback till äldre och fortfarande oförändrad data om det senaste skulle vara sönderskrivet eller inkomplett skrivet och har checksummor på all data - och det gäller även metadatat själv, och att metadatat också kan sättas i multipla kopior för redundans.

ExFAT är heller ingen bra filsystem annat än för just filtransport och det är inte noga med rättighetshantering, ägandeskap på filer, behålla filers olika tidsstämplar etc.

Den kan inte hantera sparsefiler, hårda länkar, komprimerande filsystem och andra trix som man normalt förväntar sig i en modernare filsystem.

ReFS om MS kunde göra den mer allmän tillgänglig och att man fixar saker som hårda länkar etc. så att den blir fullvärdig nog att kunna köra en OS på så hade det varit ett bättre alternativ (windows själv är jättestor användare av hårda länkar för att överhuvudtaget kunna fungera)

- men den togs fram i all hast för att MS skulle ha ett alternativ att erbjuda när NTFS inte längre räckte till i stora system pga. sin begränsning i hur många fragment filer kunde ha - och det var inte bara sakta växande filer som loggar som fick problem utan också hur filen bakom det vi kallar mappar/directory fragmenterade över tid när det över tiden fylldes på med nya filer som tex indexering av filer och bilder, thumbnails etc.

På persondator så ser man inte dessa begränsningar (som dessutom görs en dold defragmentering av de mest fragmenterade filer 1ggr i veckan även på SSD-lagring och kallar det för optimize - en nödvändighet för att NTFS skall fungera i längden) men på servrar är det andra saker och då räcker inte NTFS i längden när filsystemen blir enormt stora.

ExFAT har liknande uppbyggnad som FAT32/VFAT och det fins rätt många verktyg som har 'kunnandet' att reparera och extrahera ut filer på krachade filsystem medans på NTFS när början av $MFT och $MFT_mirr förstört så är de existerande dataräddningsverktygen väldigt dåliga att rädda ut kompletta filer utan fel och har störst chans på linjärt skrivna filer medans är filerna mycket uppdelade i fragment så är räddningsprognosen låg att få ut kompletta och felfria filer då om man inte hittar bitar av $MFT och lyckats synka in sig på dessa rätt så är det bara 'datascrape' kvar som alternativ.

Försvinner första blocket i$MFT så försvinner diskens rot upp till och med 3' directorynivån och beror på att första blocket också innehåller pekaren till fortsättningen av $MFT som kan ligga på helt annan del av disken och i värsta fallet också i småbitar spridda över hela disken.

---

med andra ord - svaret på frågan vilka filsystem man skall arkivlagra filer i och veta att de är felfria så har MS för närvarande inget att erbjuda - och de enda filsystemen som har checksumma på all sin data och bra robusthet för olika krasch-sceniarion är för närvarande bara ZFS och BTRFS (och ReFS för de som kan skapa sådana volymer med server-OS och enterprise-versioner av windows) då dessa inte skriver över redan skriven data och förstör inte för sig själv sas. och kan göra rollback till en äldre transaktion om de senaste är korrupta. Om man skapar ReFS-volymer - kom ihåg att slå på checksumme delen i samband med skapandet av filsystemet då det av någon anledning är default avslaget, medan för BTRFS och ZFS är det alltid påslaget default.

Behöver jag säga att varken ZFS eller BTRFS finns för windows i skick som man våga använda...