Linux får fullt stöd för ntfs

Nja, man vill nog inte köra Linux på en NTFS-partition oavsett. Det har sedan många år gått hur bra som helst att mounta ntfs-partitioner read/write med bra prestanda mha ntfs-3g.

Jag hade i stället gillat det mer om win fått stöd för nått välfungernda filsystem för de verkar ju aldrig våga släppa det med ReFS.
Hur officiellt blir stödet i win, är det MS som ligger bakom det via sin satsning på Linux eller är det Linus som säger att det ska funka ?

När jag provade nyligen 10 miljoner småfiler så var prestandan NTFS för windows och Linux nära samma med liten fördel för Linux förvånande nog - men det är fortfarande typ 1/5 - 1/10-del i hastighet i jämförelse native ext4/BTRFS. Eller om man säger så här - det är skillnad på dryga timmen för att skriva 10 miljoner filer i en mapp på NTFS både i linux och i windowsmiljö gentemot 6-8 min med samma program och programsnutt mot filsystem av ext4/BTRFS-typ.

I förstnämnda fallet var NTFS-drivrutinen som begränsade hastigheten och Ruby gick med 10-15% CPU och sistnämnda fallet med skrivning mot ext4/BTRFS så var det Ruby som var 100% lastat och filsystemet typ 15-25% CPU last och förmodligen var ruby flaskhalsen som begränsade skrivtakten.

Enda fördelen med NTFS på Linuxmiljöer är att det inte gör som Windows och skriver 100 GB med metadata fysiskt på disken för 10 miljoner filer och med en $MFT på ca 11-12 GB som resultat (utrymme som inte lämnas tillbaka och blir fri diskplats när man raderar alla filer igen utan är permanent låst av $MFT och enda sättet att få bort denna är att formatera om disken och skapa ny filsystem) - så testar ni med 10 miljoner småfiler med någon skriptprogram (i mitt fall Ruby) gör det inte på OS-disken i windows utan gör det på egen tom SSD.

---

Jag tycker att jag misshandlat BTRFS hur mycket som helst senaste åren utan att råkat ut för situationer som ger dataförlust men jag skulle akta mig väldigt noga att använda NTFS på externa USB-diskar och bara då om datat i två exemplar på två olika diskar man skall vara säker på att någon av de är monterbara efteråt...

Det är kombination mellan NTFS, modell av SATA-USB chip i USB-kabinetet och operationen 'Safetly remove Hardware and eject media' då det har funnits tillfällen att avstängningskommando för USB-disken kommit för tätt efter de sista 2 sektorerna som stänger NTFS och istället skrivs med slump och det bara skit av NTFS - det som ryker är första klustret av $MFT och sedan söks specifikt upp reservsektorn för $MFT som heter $MFT_mirr och och det är för att dirtyflaggan skall nollställas och tidsstämplar uppdatera det sista som görs när NTFS-filsystemet stängs - blir man av med just dessa två sektorer på en NTFS-filsystem så gör det ont på riktigt!!

Man skall också tänka på att det är en hel del skillnad på stabilitet i BTRFS hur det såg ut för 5-7 år sedan om man har dåliga erfarenheter från den tiden och hur det ser ut idag, då trots ganska tyst vistelse så filas och fixas det hela tiden på BTRFS och jag tycker den är jättestabil som klarar 'olyckor' och all min backup idag ligger på BTRFS.

Förutom idag upplevda höga stabiliteten i BTRFS så är snapshot inför ny backup något jag knappt kan leva utan idag när det gäller backupper - äntligen en filsystem där man kan både äta och ha kaka kvar samtidigt - dvs. snapshoten av en subolym påverkas inte vad som händer på orginal-subvolym man gör backuppen mot och subolymer kan tas bort oberoende av varandra för tex. generationsbackupper utan hierarkiskt struktur som man sitter fast i ZFS.