Linux 5.4 met exFat-ondersteuning is verschenen

Linus Torvalds heeft de release van versie 5.4 van de Linux-kernel bekendgemaakt. De release brengt onder andere ondersteuning voor Microsofts exFat-bestandssysteem naar de kernel. Daarnaast is de ondersteuning voor AMD-, Intel- en Qualcomm-chips uitgebreid.

Het gaat om initiële exFat-ondersteuning die gaandeweg uitgebreid wordt. De komst van de exFat-driver naar de kernel is mogelijk omdat patenthouder Microsoft de specificatie van het bestandssysteem in augustus heeft vrijgegeven en gebruik voor de Linux-kernel aanmoedigt. Het bedrijf helpt ook mee bij de implementatie. Onder andere voor sd-kaarten is exFat in gebruik.

Kernel-versie 5.4 heeft codenaam Kleptomaniac Octopus en bevat ook ondersteuning voor AMD Radeon Navi 12, Navi 14 en de komende Arcturus-gpu's, die in de eerste helft van 2020 verwacht worden. Verder is er vroege ondersteuning voor de AMD-apu's met codenamen Dali en Renoir en voor de Gen 12-gpu's van Intels Tiger Lake-generatie. Deze chips worden ook volgend jaar verwacht. Tenslotte kan de Linux-kernel 5.4 overweg met de Snapdragon 855 van Qualcomm.

Phoronix heeft een overzicht van alle nieuwe features van Linux-kernel 5.4 op een rij gezet. Eind januari of begin februari moet Linux 5.5 verschijnen. Die release moet onder andere ondersteuning voor AMD's overklokfunctionaliteit OverDrive voor Navi-gpu's brengen.

Reacties (42)

[Eonfge]

Belangrijk detail: Linux heeft al heel wat jaren ondersteuning voor exFat maar niet via de officiele Kernel. Hiervoor moet je als gebruiker gebruik maken van exFat-FUSE welke in 95% van alle distributies standaard is ingegrepen.

Het is redelijk eenvoudig voor derde partijen om modules dynamisch aan de Kernel toe te voegen. NVidia doet dit bijvoorbeeld met zijn drivers, maar ook Virtual Box doet dit. Op deze manier kunnen partijen de strenge licentie voorwaarden van Linux ontlopen, al betekend het ook dat zo'n module nooit op de eerste rang staat qua ondersteuning.

[Reactie gewijzigd door Eonfge op 23 juli 2024 16:03]

[The Zep Man]

Het is redelijk eenvoudig voor derde partijen om modules dynamisch aan de Kernel toe te voegen.

Dat systeem heet Dynamic Kernel Module Support, en is ingebakken in de meeste distributies. Zo kan je bijvoorbeeld via DKMS ook makkelijk ZFS ondersteuning aan de Linux kernel toevoegen, ondanks dat de licenties niet volledig met elkaar samenwerken. Als gebruiker kan en mag je dit doen en gebruiken, maar niet distribueren.

Verder is DKMS voor dit niet nodig, aangezien Microsoft exFAT ondersteuning direct aan de kernel tree wilt toevoegen. Het wordt dus een file system module, net als de andere beschikbare modules.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 16:03]

[ndonkersloot]

Fijn dat er nu officiele ondersteuning is vanuit de kernel. In hoever zal er verschil gemerkt worden in de praktijk ten op zichte van de fuse implementatie? Kan iemand die meer thuis is in die materie dan ik toelichting geven?

[Tux4life]

FUSE bestandssystemen draaien als user-land processen. Dit is handig (en veilig) om snel ondersteuning voor een nieuw bestandssysteem toe te voegen, maar niet echt performant omdat voor iedere operatie een context switch nodig is.

Je kunt in De lijst van processen zien hoeveel resources een FUSE mount inneemt en dat kan behoorlijk oplopen, bijvoorbeeld bij NTFS onder Linux is dat vaak het geval.

[BeosBeing]

Het opnemen van exFAT zal voor mensen die dit bestandssysteem gebruiken (bv op geheugenkaartjes in hun telefoon of hun fotokaartjes in de laptop) een betere performatie betekenen.

Toch had ik het vele keren liever gezien dat Microsoft (en Apple) ondersteuning zouden zijn gaan bieden voor flash-dedicated bestandssystemen zoals F2FS, JFFS2, UBIFS, YAFFS, LogFS, TrueFFS of CHFS. Ik heb geen idee welke de beste is, maar allemaal zijn ze beter als dat gare FAT dat zeer kwetsbaar is voor beschadigingen. Dat laatste is in exFAT niet wezelijk anders als in FAT32, FAT16 of FAT12 en echt niet meer van deze tijd.

Met een ondersteuning voor een van deze bestandsystemen zouden nu eindelijk telefoons, cameras, en geheugenkaartjes op dat robuustere bestandsysteem kunnen overstappen. Helaas zal het wel niet gebeuren zolang er nog patenten op exFAT geldig zijn en het dus Microsoft nog geld oplevert.

[Han_Solo]

Laatste zin WIKI. MS heeft ook de exFAT patenten vrijgegeven. FAT implementaties hebben bijna geen overhead en dat kan ook een belangrijke reden zijn.
WIKI:
Regardless of whether open-source or not (including Samsung's leaked kernel driver source that was initially fraudulently rebadged as GPL-licensed);[55][56] Microsoft stated that "a license is required in order to implement exFAT and use it in a product or device."[52] Unlicensed distribution of an exFAT driver would make the distributor liable for financial damages if the driver is found to have violated Microsoft's patents.[57][58] While the patents may not be enforceable, this can only be determined through a legal process, which is expensive and time consuming. It may also be possible to achieve the intended results without infringing Microsoft's patents.cf. [59] In October 2018, Microsoft released 60,000 patents to the Open Invention Network members for Linux systems, but exFAT patents were not initially included at the time. There was, however, discussion within Microsoft of whether Microsoft should allow exFAT in Linux devices,[60][61] which eventually resulted in Microsoft publishing the official specification for open usage[7] and releasing the exFAT patents to the OIN in August 2019.[42]

[BeosBeing]

Laatste zin WIKI.

Erg handig dat je niet vermeld dat dit van het wikipedia artikel van exFAT afkomt.

Dat het Samsung (makers van F2FS in 2012) is geweest die bewust of onbewust gelekt heeft is weinig relevant, behalve dan misschien dat het de reden is dat MS de patenten voor exFAT heeft vrijgegeven.

Dat MS de patenten nu vrijgegeven heeft is leuk, maar mijn betoog zegt nu juist dat exFAT juist helemaal geen geweldig bestandsysteem is en het dus jammer is dat er niet al jaren geleden een ander, beter geschikt bestandsysteem is gestandaardiseerd.

Ja dat de overhead laag is bij exFAT is logisch, het is wezenlijk niet anders als FAT12 (uit 1980) of 8-bits FAT uit 1978 destijds op je 360kb 5¼"floppies uit 1977. Ik ben niet ingegaan op de detaïls van de vele bestandsystemen die er specifiek voor gebruik met flashgeheugen zijn bedacht, maar ook daar zijn er genoeg die niet veel resources gebruiken. Afgezien van de enkelen specifiek bedacht voor SSD's zijn (TrueFFS, NILFS, OneFS, LSFS, ExtremeFFS) ze volgens mij allemaal redelijk low-overhead. JesFS is de enige waar in deze link vermeld staat "designed for very small microcontroller (16/32 bit)"

[Ayporos]

Laten we ook niet vergeten dat de gemiddelde mobiele apparaat waar zo'n ding mogelijkerwijs in zal gaan prima krachtig genoeg is om met evt. error-correcting/consistency-guaranteeing overhead overweg te kunnen zonder dat dit een al te grote negatieve invloed heeft op de gebruikerservaring.

Ik zou het zelf nl. toch nét wat meer ruk vinden als ik in het vliegtuig zit en ik kom erachter dat episode 7 van de 26 afleveringen tellende serie die ik erop gefrot heb om te kijken tijdens mijn lange vlucht corrupt is geraakt dan dat ik per episode een halve seconde langer moet wachten alvorens hij ingeladen en gebufferd is.

[BeosBeing]

Laten we ook niet vergeten dat de gemiddelde mobiele apparaat waar zo'n ding mogelijkerwijs in zal gaan prima krachtig genoeg is om met evt. error-correcting/consistency-guaranteeing overhead overweg te kunnen zonder dat dit een al te grote negatieve invloed heeft op de gebruikerservaring.

Klopt, maar gemiddelde is gemiddelde. @Han_Solo refereerde waarschijnlijk naar bepaalde (industriële en andere) embedded toepassingen waar zo min mogelijk resources gebruiken heel belangrijk is. Ik denk dan bijvoorbeeld aan apparaten die lang op een batterij moeten werken en waar corruptie door schrijffouten eigenlijk niet voorkomen omdat het geheugen tijdens het effectieve gebruik gebruik nauwelijks of zelfs niet wordt beschreven.

Toepassingen waar ik nu(misschien toch niet helemaal correct) aan denk zijn een pacemaker of icd (Implantable Cardioverter Defibrillator) die vooraf door de arts geprogrammeerd moet worden met het normale hartritme van de patient en de maximale afwijkingen naar beneden en naar boven maar daarna 10 jaar of liefst langer, mee moet kunnen gaan want nieuwe batterij betekent opereren.

Een andere toepassing is misschien de transponder waarmee natuuronderzoekers bepaalde diersoorten volgen, of zelfs filmen wat het dier doet, maar dus eenmalig tot het geheugen vol is. Mislukte beelden door opslagfouten zijn dan jammer, maar niet onoverkomelijk.

Ik zou het zelf nl. toch nét wat meer ruk vinden als ik in het vliegtuig zit en ik kom erachter dat episode 7 van de 26 afleveringen tellende serie die ik erop gefrot heb om te kijken tijdens mijn lange vlucht corrupt is geraakt dan dat ik per episode een halve seconde langer moet wachten alvorens hij ingeladen en gebufferd is.

Klopt, of dat de foto's/video's die je de afgelopen 18 maanden hebt gemaakt opeens weg zijn, zeker als dat een niet te herhalen gebeurtenis betreft zoals bevalling, eerste stapjes van je kind of de droomreis waar je 15 jaar voor hebt gespaard. De lees en schrijfacties op telefoongeheugens, camera-kaartjes en SSD's zijn behoorlijk wat ingewikkelder als de eenmalige programmeeracties in mijn bovenstaande voorbeelden.

[AmazingDreams]

Ben geen filesystem / linux expert maar ik zou zeggen dat er wel een flinke performance boost te verwachten is. Het wordt dan native ondersteund direct in de kernel in plaats van in userspace, waardoor het allemaal gewoon veel sneller kan. Zie ook de comment van Linus Torvalds over FUSE https://lkml.org/lkml/2011/6/9/462

fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device. But for something like your root filesystem? Nope. Not going to happen.

[Reactie gewijzigd door AmazingDreams op 23 juli 2024 16:03]

[84hannes]

Volgens mij kun je fuse überhaupt niet gebruiken voor een root-filesystem omdat je eerst moet opstarten voordat je fuse kan draaien, en fuse nodig zou zijn om op te starten.

[Heidistein]

Nou. Zo ongeveer, nadenkend tijdens mijn lunch zie ik geen reden waarom het niet kan. Het is een bizar slecht idee, maar toch.
Je kan prima de fusie driver en tools in je initramfs proppen, en daar al mounten. Vervolgens kan je daar wel op doorstarten.

Edit:
@The Zep Man @tweaknico Wat jullie zeggen klopt! Ik vatte dat samen in de woorden 'een bizar slecht idee' wat inderdaad te kort doen aan hoe dom het zou zijn. Ik had meer woorden moeten gebruiken. Dank voor jullie aanvulling.

[Reactie gewijzigd door Heidistein op 23 juli 2024 16:03]

[The Zep Man]

Nou. Zo ongeveer, nadenkend tijdens mijn lunch zie ik geen reden waarom het niet kan. Het is een bizar slecht idee, maar toch.

Naast de beperkte prestaties is het ook nog eens dat (vanuit een Linux perspectief) de bestandssystemen die enkel ondersteund worden in FUSE nogal obscuur zijn. Dat als systeempartitie gebruiken zou zoveel risico's (inclusief beveiligingsproblemen) opleveren en zoveel handwerk vereisen dat daarvoor bijna geen legitieme situatie is voor te stellen.

[edit]
'Bizar slecht idee' is een goede omschrijving. Ik vond alleen dat er wat technische details bij mochten. Dit is geen 'do not/only try this at home', maar een 'Do not try this. Ever.'

[Reactie gewijzigd door The Zep Man op 23 juli 2024 16:03]

[tweaknico]

Maar waarom zou je de beveiliging van je systeem overboord willen gooien?
exFAT heeft geen onderscheid in gebruiker, noch in toegangs rechten.

[twingels]

Eerst kernel (en e.v.t. initrd) door een bootloader laten laden vanaf een aparte boot-partitie (of via netwerk PXE boot), dan kan dat wel.

[DCK]

Goed te weten dat exFAT zeer waarschijnlijk ook niet gaat werken als root filesystem. exFAT ondersteunt (by design) niet het concept van permissies. Het is expliciet bedoeld als file system voor sd-kaarten en usb sticks, en andere gedeelde schijven waarbij verschillende apparaten het oneens gaan zijn over wie waar toegang toe mag hebben. Op een exfat-schijf heeft iedereen die de schijf kan openen toegang tot alles, net als met fat32.

Zonder permissies loop je waarschijnlijk heel snel tegen problemen aan bij het opstarten van Linux

[ndonkersloot]

@mrmartijn @Tux4life @AmazingDreams

Bedankt voor jullie reactie!
Mooie toevoeging aan de kernel .

[CAPSLOCK2000]

Voor eindgebruikers is het waarschijnlijk onmerkbaar. De Linux-distributies zorgen er voor dat dit soort dingen soepel lopen. Voor de beheerders van de distributie is het een stuk minder werk omdat het nu gewoon één van de vele drivers wordt in plaats van eentje die los bijgeïnstalleerd moet worden. Bij dat soort losse modules bestaat altijd het gevaar dat een driver niet 100% compatible is met een nieuwe kernel en dat dit pas wordt ontdekt/verbeterd nadat de nieuwe kernel uit is. Door de driver in de kernel op de te nemen wordt dat ondervangen, eventuele problemen worden dan opgemerkt op het moment van verandering.

[To_Tall]

Denk dat er meer bedoeld wordt als thin cliënt oplossing.

Daar zal voor je disk doorgegeven wordt aan je esp sessie toch eerst de driver geladen moeten worden. Voor de user is bij de nieuwe implementatie de usb stick of disk sneller beschikbaar en waarschijnlijk ook een hoger bestands overdracht mogelijk.

[tweaknico]

Er zijn vrij weinig Distro's die de meest verse kernel aanbieden als ondersteunde kernel.
De meeste zitten in het LTS traject en dan zijn de verrassingen wel een beetje voorbij m.b.t. compatibilteit van drivers.

[CAPSLOCK2000]

De meeste zitten in het LTS traject en dan zijn de verrassingen wel een beetje voorbij m.b.t. compatibilteit van drivers.

Dat gaat niet vanzelf, voor het zo is zal iemand de nieuwe versie moeten testen. De meeste distributies hebben daarom een ontwikkelversie waarin wel het nieuwste van het nieuwste wordt aangeboden. Gebruikers merken daar niks van maar op de achtergrond wordt er wel degelijk werk gedaan door de beheerders van de distributies. Die hebben nu minder werk omdat deze ene driver geen aparte behandeling meer nodig heeft. 99% van de drivers zit in de standaard kernel en daar hebben de distributeurs helemaal geen werk aan. Er is slechts een handjevol drivers die los wordt meegeleverd, bv via Fuse, en die kosten relatief veel werk.

[mrmartijn]

Dit is een heel stuk makkelijker voor embedded systemen, nu is het een vinkje in de kernel config inplaats van een userspace component meeleveren.

[Verwijderd]

Verwacht er niet veel van, de snelheid van de SD kaart zelf is de bottleneck.

[Lijmer]

Ik hoop dat dit dan ook uiteindelijk beschikbaar wordt op Android One. Het is nu erg onhandig dat je alleen maar FAT-32 kan gebruiken voor je SD kaartje.

[jqv]

Wat vind jij daar onhandig aan?
Het werkt naar behoren zoals het nu is.

[HeepH]

FAT32 ondersteunt geen files groter dan 4GB. Met de toenemende grootte van SD cards tik je die limiet nog wel eens aan...

[Titan_Fox]

In Linux kun je vaak voor EXT3/4 kiezen, maar aangezien dat logging / journaling filesystems zijn die veel schrijfbewerkingen uitvoeren zijn die minder geschikt voor opslagmedia gebaseerd op flashgeheugen.

P.s. Leuk je weer eens te zien, Stephan

[dingo35]

Theoretisch is dat waar.

Praktisch gesproken draai ik nu alweer een jaar of vijf een volledige LAMP server, plus dovecot, owncloud, shadowsocks en nog wat andere (lichte) services op een Raspberry Pi 3 met SD card, zonder enig probleem....

[Ventieldopje]

Als je alle logging uitschakelt of via rsyslog gaat lopen dan werkt dat vast prima, anders gaat de levensduur toch wel enorm achteruit vaak.

[fastedje]

Je kan daarvoor ook extra (riskantere) mount opties gebruiken zoals 'nobariers'. Beter is het om flash media als een read-only volume te gebruiken. Loggen kan je dan b
v. in een tmpfs ramdisk doen, of naar een share op een nas.

[Lijmer]

Dat is helaas ook geen optie op Android One (heb ik namelijk ook geprobeerd).

[BeosBeing]

Daar heb je dus niet veel aan als je camera dat niet ondersteund.

Zelfs Android telefoons, die dus onderhuids op Linux draaien, ondersteunen het niet.
Er is een plan van Google om Android op de default kernel te laten gaan draaien, dus dan zou Android wel F2FS (in de kernel sinds 3.8) gaan ondersteunen. Zover is het helaas nog niet.

[CaDje]

Kan mij voorstellen dat een 4GB bestand limiet niet handig is, vooral voor de grote SD kaarten die momenteel op de markt zijn.

[BeosBeing]

Met video zit je er zo overheen, zeker als je 4K@60fps schiet.

[TheVivaldi]

Dat zei men ook ooit van de draaitelefoon en papieren krant, en eigenlijk alle pre-internetdingen.

[tweaknico]

Ext4 mag ook op het kaartje als je dat wil...

[michielRB]

Het is een goede ontwikkeling dat er op kernel niveau een cross-platform bestandssysteem beschikbaar komt. Maar als je eenmaal de permissie mogelijkheden van linux bestandssystemen gewend bent, dan wil je echt niet meer terug naar een antiek systeem als ex-fat.

[leuk_he]

Beetje verbaasd dat het 5.4 nog gehaald heeft:

https://www.phoronix.com/...=Linux-exFAT-Code-Staging

in augustus was de code nog "horrible".

[Robby517]

De project manager heeft de devs waarschijnlijk pizza beloofd als ze de release haalden.

[HollowGamer]

Ik heb een beetje mixed feelings, tot nu toe heb ik enkel gelezen hoe slecht de implementatie zou zijn:
https://www.phoronix.com/...=Linux-exFAT-Code-Staging

Mooi dat Intel en AMD stappen maken om nieuwe hardware te ondersteunen out-of-the-box. Helaas blijft het behelpen en is er nog genoeg patching nodig en zit je dus nog min. één maand na release met workarounds of helemaal niets: zo was de nieuwe Ryzen-serie niet compatibel met Linux 5.* en datzelfde is ook altijd met Intel het geval.

Ik ben overigens meer benieuwd naar de merges van Google, die willen hun Android spul volledig op de Linux-kernel laten draaien. Het zou mooi zijn als die verbeteringen ook allemaal terecht komen in nieuwe releases.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 16:03]

[HaerdenCliff]

Snapdragon 855 ... dat vind ik een beetje raat want die is toch al min of meer courant en goed ondersteund door android.

[Belgar]

Via een binary package die wordt toegevoegd via kernel API's, niet via de kernel zelf.

Dat is ook de belangrijkste reden dat android voor sommige telefoons in sommige gevallen nog op een linux kernel van 7 jaar geleden draait. De binary packages zijn veelal specifiek aan een kernel versie en qualqomm en andere partijen weigeren hun packages te recompilen tegen nieuwere kernels. Er zit dan niets anders op voor die telefoon om de oude kernel te gebruiken. Anders kun je geen android compilen die werkt met die specifieke telefoon.