Linux-kernel 5.15 met nieuwe NTFS3-driver is uit als lts-release

Linux-kernel 5.15 is uitgebracht. Die versie wordt de nieuwe long term support-release en wordt tot zeker oktober 2023 bijgewerkt. Nieuw in de kernel is onder andere de toevoeging van de NTFS3-driver en de ksmbd-driver voor smb-bestandssystemen.

Hoofdontwikkelaar Greg Kroah-Hartman schrijft dat kernelversie 5.15 de volgende lts-release voor Linux wordt. Eerder was nog niet bekend of dat 5.15 zou worden, of toch versie 5.16 die naar verwachting begin volgend jaar pas uitkomt. Op de releasepagina staat dat 5.15 een lts-release is. De huidige end-of-life daarvan loopt tot oktober 2023, maar bij eerdere lts-releases werd de eol vaker verlengd als er genoeg ondersteuning vanuit de community komt. De huidige lts-release, kernel 5.10, heeft een levensduur tot december 2026.

In kernel 5.15 zitten een paar grote veranderingen in met name het filesystem. Zo wordt NTFS3 toegevoegd als een vervanger van NTFS-3G, al blijft die laatste wel bestaan. Ook wordt ksmbd toegevoegd, een smb-driver die direct in de kernel zit. Ook wordt dram voortaan in persistent geheugen geplaatst, en zijn er meerdere optimalisaties doorgevoerd voor EXT4.

De kernel biedt ook ondersteuning voor verschillende nieuwe hardware. Zo sorteert de kernel voor op mogelijke installatie op Apple-apparaten met de nieuwe M1-soc, en is er ondersteuning voor Intels aankomende Alder Lake-chips en AMD's Navi-apu's.

Reacties (82)

Wat voor use-cases, behalve het troubleshooten van een problematische Windows schijf, zijn er nou eigenlijk voor NTFS ondersteuning in Linux?

Twee veel voorkomende use-cases:

• Externe schijven geformatteerd met NTFS
• Dualboot situatie met windows met een data partitie

Een USB stick met ondersteuning voor grote bestanden (+4GB) die uitwisselbaar is met Windows computers misschien?

Ik gebruik daarvoor al een tijdje exfat tussen mijn windows en apple machines. Volgens mij werkt dat ook in Linux.

Met Raspberry Pi OS vond ik dat niet fijn werken. Ook met dingen als ex-fuse vond ik het niet stabiel/betrouwbaar.
Knap vervelend, want voor macOS is NTFS weer een ramp. Om maar niet te spreken over ext04.

Zou prettig zijn als er een mooie goed werkende open source file system zou bestaan en wat dan ook door de hele markt ondersteund wordt.

Knap vervelend, want voor macOS is NTFS weer een ramp. Om maar niet te spreken over ext04.

Eigenlijk niet, als je geen problemen hebt met proprietary software dan is er Paragon ExtFS en Paragon NTFS voor macOS. Dat werkt fantastisch (komt vast wel weer een sale met BF). Ze hebben zelfs een APFS driver voor Windows.

Er is ook een FOSS Btrfs driver voor Windows, en er zijn ExtFS FOSS drivers voor Windows. Met userspace (FUSE) kom je een heel eind op Linux, helaas werkt FUSE niet meer goed op macOS, en op Windows zit je dan met Dokan.

Vooralsnog zou ik voor Ext4FS gaan (met een vorm van FDE als dat nodig is, zoals VeraCrypt). Overal op te lezen en schrijven. Soms helaas wel met third party tools die root vereisen.

De prijzen van paragon zijn niet zo absurd als je het mij vraagt. 2 tientjes voor de Ntfs driver voor Mac en 5 tientjes voor de apfs driver voor Windows.

Als je het echt nodig hebt zijn dit de kosten niet (als ik een Mac zou hebben zou ik sowieso de ntfs driver kopen. Dit maakt onderling gebruik van drives tussen Windows en Mac een stuk makkelijker zonder dat je elke Windows gebruiker in de portemonnee schiet)

Mee eens. Ik heb die APFS driver dacht ik gratis gekregen destijds als package deal. Als je een Mac shop bent met veel Macs en weinig Windows, zou ik voor native APFS gaan. Ik denk dat APFS ook betere data integrity heeft met CoW.

EDIT: Paragon heeft ook een APFS driver voor Linux zag ik zojuist. Er lijkt ook een gratis APFS voor Windows driver te zijn: https://manjaro.site/how-to-mount-apfs-volume-on-windows-10/

[Reactie gewijzigd door Jerie op 2 november 2021 13:33]

Fat32, f2fs, vfat/exfat

ext4 is natuurlijk gewoon Open Source (GPL).

Overigens is een formaat strikt genomen niet Open-Source, maar de driver ervoor. Dat zie je wel aan dit project: NTFS is een Microsoft formaat maar deze Linux driver is niet afgeleid van Microsoft's NTFS driver op Windows.

Alles is voor de Linux kernel netjes gedocumenteerd. Ook OpenZFS en HAMMER hebben uitgebreide documentaries. Makers van closed source kernels kunnen filesystem drivers hiervoor implementeren, maar weigeren dat meestal te doen.

Sinds Linux 5.4 zit exFAT met goedkeuring van Microsoft standaard in de kernel en hoeft het niet meer via FUSE. Ik vind het perfect werken voor USB-drives die cross-platform moeten werken.

Zover krijg je Microsoft niet. Incompatibiliteit is hun verdienmodel.

Datzelfde kan je zeggen voor Apple en zelfs Linux tot zekere hoogte. Microsoft maakt toch echt forse stappen als het gaat om opensource, bijvoorbeeld door WSL. Hun verdienmodel is al lang geen Windows dozen schuiven meer, maar juist IaaS en corporate accounts.

Maar Windows is de gateway naar de Azure cloud. Zonder Windows is er geen grote conversie naar Azure, maar eerder naar AWS en andere cloud providers.

Maar dat is puur om hun eigen hachje te redden. Microsoft kan niet zonder Linux, in heel veel opzichten. Het WSL verhaal bijvoorbeeld is puur zodat ICTers op Windows blijven ipv overstappen naar Linux of Mac.

OpenZFS ondersteunt nu Linux en FreeBSD als Tier 1 OS. macOS is nu nog Tier 2 OS maar wordt binnenkort Tier 1. Daarna wordt Windows mogelijk een Tier 1 OS en dan kun je dezelfde schijf delen met de vier grote OS-en.

Maar, dat is wel een vrij serieus en full-featured filesystem. Dat zou ik nooit gebruiken voor even bestandsuitwisseling via USB stick of iets dergelijks.

Leuk dat jij dat gebruikt, maar er zijn vast ook mensen in de wereld die hun schijf als NTFS geformatteerd hebben, en die toch een keer zouden willen lezen op hun Linux PC. Ik denk niet dat de schijf eerst formatteren als exFAT, om dan vervolgens de files die erop stonden niet meer te kunnen lezen voor die mensen gewenst is.

On-topic: het belangrijkste aan het hele verhaal, is dat NTFS3 nu een kernel-level filesystem driver is (net als bijvoorbeeld ext4, xfs, btrfs en anderen zijn), in tegenstelling tot NTFS-3G die FUSE gebruikt, en daardoor in userland draait. Ik begreep uit de discussies in de mailinglists ook dat er heel veel verbeteringen zijn doorgevoerd in NTFS3 vs NFTS-3G, wat de stabiliteit en performance voor het lezen van NTFS schijven alleen maar ten goede zou moeten komen.

Daar heb je gelijk in. Ik heb ook nog een schijf als NTFS geformateerd en die ligt in de last. Als ik op een gegeven moment een andere schijf haal, kopieer ik alles over naar een ext4 partitie. Dan formatteer ik de huidige schijf ook als ext4 en heb ik geen NTFS meer.

Verder kan NTFS in de kernel nuttig zijn om data te herstellen van een Windowsschijf, als Windows niet meer wil opstarten. Dat is altijd de belangrijkste reden geweest om onder Linux een NTFS driver te hebben.

ExFAT is inderdaad een goede optie. In alle drie platforms R/W.

Exfat heeft toch ook aardig wat nadelen ten opzichte van NTFS of, bij flashgeheugen - waarvoor exfat veel gebruikt word - ten opzichte van specifiek voor flashgeheugen ontwikkelde filesystems, zoals F2FS, LogFS, UBIFS, JFFS, JFFS2, YAFFS...
De enige voordelen van exfat is dat het een doorontwikkeling is van Fat32, Fat16, Fat12 waardoor er weinig aanpassingen aan bestaande drivers nodig zijn, en dat het (mede daardoor) door bijna alle devices ondersteund wordt

Daarvoor heb je zoals @CaDje al aangeeft exfat, ook heb je verschillende opensource/commerciële mogelijkheden zodat je ext4 (er zijn ook voor andere FS'en) kan openen op iets als Windows/OS X of je gebruikt daarvoor een VM als VirtualBox.

Toegeven het NTFS het eenvoudigs en waarschijnlijk het beste is als je gewoon native ondersteuning wilt hebben aangezien exfat ook weer features mist.

NTFS is een veelgebruikt bestandssysteem in de Windows-wereld, en de Windows-wereld is een groot deel van de wereld. Voor compatibiliteit is het heel prettig als je daarmee om kan gaan.
Misschien heb je usb-sticks en externe hdd's die je zowel op Windows als op Linux wil gebruiken. Mijn laptop heeft een Windows/Linux dual-boot met een gedeelde NTFS-geformatteerde data-partitie. Het liefst zou ik Ext4 of Btrfs gebruiken, maar die mounten op Windows is meer gedoe dan NTFS mounten op Linux.

Ik ben een newbie en nitwit vergeleken met velen, maar ik snap de issue hier maar gedeeltelijk, dit met betrekking tot de discussie dual boot linux - windows.

Tien jaar geleden had ik een dual boot met gedeelte schijven en Thunderbird mail werkte aan beide kanten. Windows XP (met behulp van ext2fsd, ext2ifs en mogelijk Linux-Reader, helaas niet meer mogelijk om de zaak te repliceren) en Ubuntu 8.04. Linux met (maar dat weet ik niet zeker meer) of ReiserFS of Ext3.

Nu een machine met LinuxMint en Windows 7 en nog steeds gedeelde schijven. Alleen Windows 10 is "not
playing nice". Continue wil 10 een diskcheck doen.

Met een NTFS driver zou je als je op je dual boot systeem Linux draait je NTFS drive kunnen openen om daar data vanaf te halen. Zonder NTFS of ext3/4 driver kun je op je dual boot systeem niet bij de data van het andere OS.

Met een dualboot systeem zou het wel prettig zijn om goede ondersteuning voor NTFS te hebben op een data schijf.

Dual boot is 1 van de redenen die ik kan bedenken. Hiermee kan je bijvoorbeeld de een schijf delen tussen Windows en Linux.

Ik gebruik al jaren Linux als hoofdOS (daarnaast o.m. Haiku en AmigaOS 4), maar mijn externe harde schijf is altijd geformatteerd in NTFS.

Delen van app data in een dual boot situatie. Bijvoorbeeld gedeeld Firefox profiel, of een gedeelde Steam directory. Hoeven niet eens dezelfde gebruikers te zijn.

Naast zaken als externe-schijven en dual-boot denk ik dat virtualisatie ook een grote drijver is: Heel veel hosts gebruiken een linux kernel. Daarbij is ook toegang tot het file systeem van de gasten wenselijk.

Ik dual boot en moet af en toe wel eens iets van mn windows schijf hebben, dus dan is het handig als het gewoon werkt.
Maar ntfs levert ook wel eens problemen op, proton (de wine fork van Valve) heeft geregeld issues met ntfs en ik help redelijk vaak mensen die proberen games met proton te draaien vanaf een ntfs partitie, het werkt gewoon niet, ext4 of btrfs is het enige wat er goed mee werkt.

usb schijven

USB sticks en externe schijven die ook in Windows gebruikt worden.

Mensen met een Windows-GNU/Linux dual-boot zodat ze op beide OSen dezelfde partitie kunnen gebruiken voor hun Steam games en niet alles dubbel hoeven hebben te staan.

Apple Silicon met fatsoenlijk werkende Linux zou ik echt goud vinden. De hardware is super, maar ik heb een pesthekel aan MacOS.

Apple Silicon met fatsoenlijk werkende Linux zou ik echt goud vinden. De hardware is super, maar ik heb een pesthekel aan MacOS.

De ontwikkeling daarvan gaat sneller dan gedacht. Grootste pijnpunt leek heel lang de GPU te gaan worden, maar door het uitstekende werk van Alyssa Rosenzweig lijkt ook daar licht aan het einde van de tunnel.

Wow, dat is inderdaad indrukwekkend. En veel sneller dan ik had verwacht.

Dat geloof ik ook allemaal best wel, en zonder de touchbar is dat probleem ook al weer opgelost (geestig genoeg zat daar ook de T2 in, en was een soort van combo deal om het erdoorheen te jassen. 3x raden wat blijft bestaan want native ARM).

De vraag is eerder of en in hoeverre de trackpad met gestures werkt in Linux.

Die verwacht ik tegen het eind van het jaar en anders moet er ondersteuning zitten in distributies die in de eerste helft van 2022 uitkomen. Het enige echte grote ding dat nog toegevoegd moet worden is 3D-versnelling. Maar ook zonder die 3D-versnelling werkt het al zeer vlot. De Mac Mini M1 zou perfect zijn als Linux machine, terwijl de M1 Pro en Max voorlopig nog macOS kunnen blijven draaien tot de ondersteuning daarvoor in Linux ook in orde in gemaakt.

Ik wacht ook nog tot alles goed werkt. Misschien is er volgend jaar ook snelle ARM hardware van andere fabrikanten, maar anders zijn de Apple M1 apparaten tegen die tijd een redelijk alternatief.

Wat betreft macOS, daar zitten veel bugs in tegenwoordig en het haalt rare zaken uit. Ik heb Big Sur geïnstalleerd staan in QEMU op mijn laptop, maar weet niet of ik dat kan gebruiken zonder Apple ID en hoe het zit met toolchains buiten Xcode om. Misschien moet ik eens kijken naar Kdevelop en CLion met een losse LLVM/Clang om niet constant lastig gevallen te worden door de beperkingen Apple.

Ik zou het eerder andersom hebben, MacOS ziet er prachtig uit en voor ontwikkelaars zijn er genoeg features aanwezig. Vergeleken met Linux ontbreken er nog genoeg zaken als app permissies, goed werkende HW-acceleratie en is er een interface dat wel een vaste stijl lijkt te hebben.

Zelf gebruik ik gewoon Linux (Arch btw), maar is er nog altijd geen geheel. Die app permissies implementatie is weer afhankelijk van het package systeem en laten we vooral fatsoenlijk 4K met een normale batterij duur niet vergeten. Daarnaast is iets als Wayland nog steeds niet helemaal klaar om X11 te vervangen (vooral KDE loopt hier tegenaan).

De hardware van Apple vind ik daarin tegen weer heel slecht, veel lijm en dingen die jezelf niet (eenvoudig) kan vervangen. Als je garantie wilt claimen heb je een probleem, zelfs als dit een ontwerp fout is, daar is meestal eerst een (dreigende) rechtzaak voor nodig om in aanmerking te komen voor gratis reparatie.

Linux zet met deze milestone natuurlijk ook weer mooie stappen, vooral naar de SMB implementatie kijk ik uit - die loopt ontzettend achter op iets als NFS performance (incl. als je van SMB features uitzet of tweakt). Er zijn ook weer andere kleine verbeteringen die niet (altijd) worden genoemd, zoals eindelijk ZEN3 sensors kunnen uitlezen.

Al met al een mooie LTS, al gebruik ik op de desktop altijd de laatste stable versie.

[Reactie gewijzigd door HollowGamer op 2 november 2021 11:02]

Een fatsoenlijk werkende Hackintosh zou pas mooi zijn, ik vind MacOS best fijn werken - zeker vanuit het oogpunt van een desktop gebruiker - maar de hardware is onnodig duur.

Hackintosh zal in de toekomst heel moeilijk gaan worden. Op een dag komt er een macOS versie uit die alleen nog maar draait op Apple Silicon en die dus geen Intel x86 meer ondersteunt. Dan wordt het vrijwel onmogelijk om op een willekeurige zelfgeknutselde PC, waar geen Apple Silicon in zit, nog macOS te draaien.

Er bestaan natuurlijk al ARM processoren en dat zullen er steeds meer worden. Hackintosh projecten zullen dus op een gegeven moment ook gaan switchen om macOS op andere ARM hardware te laten draaien, zeker als macOS op een gegeven moment de ondersteuning voor x86 laat vallen. Makkelijk zal het niet worden maar dat is voor sommigen juist een uitdaging.

Tenzij Apple vereist dat bepaalde Apple-only hardware op de SoC aanwezig is om MacOS te draaien. Het zou me verbazen als dat al niet het geval is.

Jep, de smc. Die kun je faken, doet alle software zoals opencore ook

Je kunt veel faken, maar een cryptografische co-processor faken zal nogal lastig worden.

https://bitbucket.org/Reh...fakesmc-kozlek/downloads/
Onder andere, je hebt er meer ;-)

Ik deel die vrees! Heb zelf veel ervaring met Open Core.

Een fatsoenlijk werkende Hackintosh zou pas mooi zijn, ik vind MacOS best fijn werken - zeker vanuit het oogpunt van een desktop gebruiker - maar de hardware is onnodig duur.

Wat houdt je tegen? Alles is tegenwoordig goed gedocumenteerd. Ik heb Hackintoshes gebouwd voor zeer veeleisende gebruikers. Check deze site en je komt een heel eind :-)

https://caizhiyuan.gitee.io/opencore-install-guide/

Ik vraag me af iemand al een ARM Hackintosh heeft geprobeerd te draaien op basis van bijvoorbeeld een Honeycomb LX2K of een Ampere workstation. De ondersteuning voor Intel gaat de komende toch alleen maar meer achterlopen.

Ik net omgekeerde. Pest aan de hardware maar ik vind MacOS wel prettig werken

Ook wordt dram voortaan in persistent geheugen geplaatst

Hoe moet ik dit zien? Is dram niet je geheugen en per definitie volatiel?

Het is erg kort door de bocht vertaald door Tweakers.

Landing via Andrew Morton's patch series today in the Linux 5.15 kernel is handling for demoting pages during memory reclaim, which can be used for punting cold pages off to slower, tiered memory devices (like Intel persistent memory) when under system memory pressure.

The current behavior with Linux right now is when the system memory (RAM) fills up under memory pressure, some of the DRAM contents will be tossed out. For recent and future servers with tiered memory like using Intel Optane DC persistent memory, the Linux kernel may eventually fall over to start using that persistent memory if necessary for allocations but not in any intelligent manner.

Dus het komt eigenlijk neer op slimmere paging/swapping, waarbij Optane bijvoorbeeld toegepast kan worden.

Ahaa, dat is al een heel ander verhaal! Bedankt. Het is me helaas al vaker opgevallen dat Tweakers soms aardig slordig omgaat met vertalingen en met halve verhalen op de proppen komt. Het lijkt soms alsof ze niet begrijpen wat er eigenlijk staat en dan maar een halve vertaling neerplempen.

Wat betekent dit?

Zo sorteert de kernel voor op mogelijke installatie op Apple-apparaten met de nieuwe M1-soc

Kernel specifiek voor M1 ipv generieke arm kernel maybe?

Arm zegt eigenlijk alleen iets over de instructies die de CPU-kernen uitvoeren. De peripherals daaromheen (GPU, Memory management, timers, communicatiebussen, noem maar op) zullen allemaal een speciaal Apple-sausje hebben en uitgezocht moeten worden.

Memory management is een OS verantwoordelijkehid, geen CPU taak. Dat heeft dus geen Apple-sauce nodig. AArch64 definieert ook gewoon timers, dus het zou me verbazen als Apple daarvan gaat afwijken. De communicatie-bus is PCIe, dus ook die is niet zo bijzonder. De GPU lijkt me de grootste complicatie.

Memory management is een OS verantwoordelijkehid, geen CPU taak.

Ik denk dat @CykoByte het heeft over de MMU die load/store en virtual memory regelt, dat zit bij ARM in de CPU.

Inderdaad, daar miste nog een "Unit"

Absoluut, met alleen compileren naar ARM ben je er nog lang niet. Er zit allemaal hardware in en rondom de M1 die uniek voor Apple is. Daar moet je dus drivers en dergelijke voor ontwikkelen die nu nog niet bestaan voor Linux.

Zo sorteert de kernel voor op mogelijke installatie op Apple-apparaten met de nieuwe M1-soc

Met dergelijke experimentele ontwikkeling zou ik denk ik liever de bewuste developers willen volgen die dit probeert te ondersteunen:
En die heeft al versies met 5.16 staan. (@Clevergyno )

[Reactie gewijzigd door scholtnp op 2 november 2021 10:23]

Ik denk dat je het als pijplijn moet zien. De mensen achter het Asahi project doen het ontdek- en ontwikkelwerk om dit aan de praat te krijgen. De onderdelen van hun werk die inmiddels goed genoeg zijn begin je nu terug te zien in de gewone Linux kernel. Vandaar ook "voorsorteren".

Volgens mij is sowieso het doel van Asahi om dit uiteindelijk allemaal gewoon in de reguliere kernel te krijgen.

[Reactie gewijzigd door Maurits van Baerle op 2 november 2021 10:39]

Vermoedelijk bedoelen ze dat ondersteuning voor de M1 er aan komt:

quote: https://www.phoronix.com/...x=Linux-5.15-Feature-Look

- The Apple M1 IOMMU driver was added among other ongoing work around bringing up mainline support for Apple Silicon with the Linux kernel. For Linux 5.16, more work is on the way.

Er zit nu ook een hele Samba server in de Kernel, blijkbaar van Samsung om in Android sneller dingen te kunnen delen (https://www.phoronix.com/...=SMB3-KSMBD-Linux-5.15-PR)

Een in-kernel file-server. Dat klinkt als vragen om problemen.

[Reactie gewijzigd door CykoByte op 2 november 2021 11:01]

Linux heeft al sinds mensenheugenis een in-kernel fileserver, namelijk nfs. Waarom zou samba dan een probleem moeten zijn?

NFS kan ook problemen geven.

Er zijn al meerdere CVE's geweest waarmee de kernel aangevallen kon/kan worden, zowel remote als lokaal, via bugs in de NFS-implementatie.

Zie bijvoorbeeld CVE-2010-2521, CVE-2018-16871, CVE-2021-38202 en anderen.

Uhm, het ik wel een beetje twijfelachtig ja. Er bleek in inderdaad al een beveiligingsfout in te zitten na een week:
https://www.phoronix.com/...-File-Server-Security-Fix

Dat gezegd hebbende, er zijn ook wel use-cases voor te stellen waarbij het handig is om SMB op dit niveau te hebben. De Kernel is immers verantwoordelijk voor het wegschrijven van bestanden naar de disk, dus als je dit proces uitbreid met wat extra management logica, dan kun je een veel hogere schrijfsnelheid halen.

Zover ik weet staat deze file-server niet standaard aan trouwens, dus kernel maintainers zullen deze functionaliteit moet aanzetten, en ik kan mij best voorstellen dat alleen Samsung dat gaat doen.

en ik kan mij best voorstellen dat alleen Samsung dat gaat doen.

Dat is even afwachten. Ik kan me zomaar voorstellen dat als er bedrijven zijn die veel SMB-servers gebruiken dat zij dan graag dit als kernelmodule willen hebben draaien, onder andere vanwege de potentiële snelheidswinst die je zelf aanhaalt. Dus er is een goede kans, dat wanneer de module stabiel en veilig blijkt dat de RedHats en Suses van deze wereld de module gewoon gaan aanbieden.

Ik kan me ook voorstellen dat NAS-boeren het graag als kernelmodule willen laten draaien.

Dat geldt eigenlijk voor elk netwerk protocol in de kernel.

De voordelen zijn groot doordat geen geheugen switch kernel<->userspace plaatsvindt en evt. direct NIC kan worden gebruikt zonder tussenkomst CPU.

Kleine correctie. Je bedoelt hetzelfde, maar er zit een groot verschil in.

Het is een SMB3-server. SMB (versie 3 dus) is een protocol dat is ontworpen door Microsoft. Samba is een applicatie die ook als SMB-server kan fungeren.

Ter vergelijking:
Apache is een applicatie (of middleware afhankelijk van je definitie), welke kan werken als een webserver:
Een webserver is (versimpeld gezegd) een server die het HTTP-protocol serveert. Er bestaan meerdere webservers (Apache, nginx, MS-IIS, enz. enz. enz)

Samba is een applicatie (of middleware afhankelijk van je definitie), welke kan werken als een SMB-server.
Een SMB-server is een server die het SMB-protocol serveert. Er kunnen meerdere SMB-servers bestaan: Persoonlijk ken ik alleen Windows machines en Samba voor niet-windows machines. (allicht dat iemand anders er nog één kent)

(( disclaimer: Bovenstaande is incompleet aan informatie, maar het gaat even om het idee ))

Yes, je hebt helemaal gelijk, bedankt voor de correctie.

Dat er de optimalisaties van ext4 in dezelfde versie als de introductie van de nieuwe in-kernel NTFS-driver (NTFS3 / Paragon's NTFS driver) komen, lijkt geen toeval te zijn.

Bij de benchmarks van Theodore Ts'o van de nieuwe NTFS3 in-kernel driver en NTFS-3G user-space driver (te vinden via dezelfde link), zijn de verschillen in performance niet geheel verrassend, maar zeker van harte welkom

[Reactie gewijzigd door RoestVrijStaal op 2 november 2021 13:07]

Wordt dit ook de kernel voor de aankomende LTS-release van Ubuntu?

Dat ik bij windows geen extra filesystemen kan installeren, althans niet met officiele ondersteuning, vind ik erg jammer.

Ik zou graag voor bepaalde toepassingen copy-on-write hebben, bijvoorbeeld voor backups of andere situaties waarin meerdere versies van dezelfde bestanden hebben handig is.

File history is al een tijdje een ding in Windows.
Control Panel\System and Security\File History

Gezien de grote hoeveelheid 'microsoft' producten die steeds meer en betere ondersteuning krijgen in de linux wereld en in de linux kernel, krijg ik steeds meer het idee dat microsoft zelf best veel linux gebruikt. Bijvoorbeeld als fundering voor haar eigen cloud installaties en dergelijke.

Het zou mij zelfs niets verbazen als de microsoft windows nano server is gebaseerd op de linux kernel.

Azure draait al sinds het begin op NT, Azure was ook heel even de enige NT gebaseerde 'supercomputer' in de Linpack top 500. Nano Server is ook gewoon gebaseerd op Windows Server, wat ook NT is.

Ze verspreiden meestal wel de Windows ISO's e.d. via Akamai, welke Linux servers gebruikt. Wat ergens wel komisch is.

NT gaat nergens heen, het werkt zo drastisch anders dan Linux. Dat Microsoft alles wat daar boven op zit, heel Azure en Windows, compleet mag gaan ombouwen. NT heeft in veel opzichten gewoon een beentje voor op Linux.

NT gaat inderdaad nergens heen. Maar als het ergens heen gaat, is dat waarschijnlijk Mars. Of misschien gewoon de prullenbak in. We weten het niet en alles is mogelijk. We duimen in ieder geval voor NT.

Microsoft forceert zich overal in en dat is ook een manier om betere ondersteuning voor je eigen producten in te bouwen. Het interesseert me eigenlijk niet zo wat Microsoft precies gebruikt als fundering voor de cloud installaties, zolang het maar goed werkt.
Althans als ik gebruik maak van Azure.

En ik maar denken dat SMB een protocol is en niet een bestandssysteem.
Heb ik er nou al die tijd naast gezeten?