Linux 6.9 stopt met ondersteuning voor ext2-driver

Linux biedt vanaf versie 6.9 niet langer ondersteuning voor de ext2-driver. Het gebruik van het ext2-bestandssysteem loopt al jaren terug, aangezien het inmiddels is opgevolgd door ext3 en ext4.

Ext2, of second extended file system, is een bestandssysteem voor de Linux-kernel en bestaat al zo'n dertig jaar. Lange tijd was dit het standaard bestandssysteem in diverse Linux-distro's. Zo'n twintig jaar geleden werd echter ext3 toegevoegd aan de Linux-kernel en meer dan een decennium geleden volgde ook ext4. Daarop liep het gebruik van ext2 terug.

De ondersteuning voor de ext2-driver stopt nu omdat deze geen data na het jaar 2038 ondersteunt, als gevolg van het Y2038-probleem. Dat probleem komt voor bij systemen die tijd bijhouden in Unix-tijd, ofwel de hoeveelheid seconden die verstreken zijn sinds 00:00:00 UTC op 1 januari 1970. Dat wordt bijgehouden in een 32-bit integer, maar die bereikt op 19 januari 2038 om 03:14:07 UTC de maximale waarde. De integer gaat dan door naar een negatieve waarde, waarop de datum wordt aangegeven als 13 december 1901.

Gebruikers die nog ext2 gebruiken, worden door Linux-ontwikkelaars geadviseerd om te upgraden naar de ext4-driver. Deze driver heeft geen last van het Y2038-probleem en ondersteunt ook het ext2-bestandssysteem. De code van de ext2-driver blijft nog wel aanwezig als referentie voor ontwikkelaars van bestandssystemen.

Reacties (75)

[vanaalten]

Ik had eerst iets van "nog 14 jaar te gaan en dan NU al mensen forceren over te stappen?!?" maar de laatste alinea:

Gebruikers die nog ext2 gebruiken, worden door Linux-ontwikkelaars geadviseerd om te upgraden naar de ext4-driver. Deze driver heeft geen last van het Y2038-probleem en ondersteunt ook het ext2-bestandssysteem

... ze forceren een kleine config-wijziging in je systeem wanneer je update naar een nieuwe kernel, maar je hoeft niet je disken opnieuw in te richten, kan gewoon ext2 als bestandsysteem blijven gebruiken blijkbaar. Daarmee vind ik het stoppen met de ext2 driver begrijpelijk.

[BRAINLESS01]

Je hebt het stuk gemist waarin verteld wordt dat ext2 sowieso al niet veel meer gebruikt wordt? Er zijn waarschijnlijk maar weinig mensen over die ext2 gebruiken én upgraden naar Kernel 6.9. Upgrade je niet, dan is er niets aan de hand. Heb je een recent systeem, dan is de kans dat je nog ext2 gebruikt extreem klein. Begrijpelijk dat ze er nu mee stoppen, het is 30 jaar oud en zelfs de 2 opvolgers zijn inmiddels al oud (ext4 was stabiel in 2008), waarvan er één zelfs compatibel is.

Oude software onderhouden kost stiekem een hoop ontwikkeltijd, op deze manier hoeven ze niet meer naar ext2 om te kijken en kan die tijd besteed worden aan dingen die nog wel actief gebruikt worden.

[Student1563424]

Ik gebruik Ext2 nog steeds voor flash storage die aan een tomato router hangt omdat het minder writes pleegt.

[ookhoi]

Ik gebruik Ext2 nog steeds voor flash storage die aan een tomato router hangt omdat het minder writes pleegt.

Je kan ook ext4 zonder journal gebruiken. Dan heb je alle moderne features van ext4 met minder write en iets betere performance:

mkfs.ext4 -O ^has_journal /path/naar/device/

[Reactie gewijzigd door ookhoi op 23 juli 2024 13:15]

[Jay-v]

Tomato, welke nog op Linux kernel 2.6 draait heeft hier dus geen last van ;-)

[arjan1995]

Maar is wel te hacken vrees ik. Linux 2.6 is echt extreem oud en wordt al lang en breed niet meer ondersteund.

[Azbest]

En dan nog niet over recovery gesproken. Recovery van data op ext4 is echt waardeloos. ext2 werkt gewoon (gebruik het om deze reden ook nog).

https://www.jooch.nl/jooc...linux-why-ext4-sucks.html

[c-nan]

Waarom vind je het waardeloos? Zowel jij als het artikel trekt die conclusie wel erg snel. Als ik een bestand permanent verwijder dan moet het ook permanent zijn. Omdat ext4 de informatie/meta data over je verwijderde bestand cleared is het een waardeloos filesystem?

[TrekVogel]

Dit is toch gewoon hoe je zou verwachten dat een FS werkt? Je kan in Linux alles per ongeluk slopen als je niet weet wat je doet. Dat maakt het niet slecht.

[Azbest]

In een productie omgeving komt het vaak genoeg voor dat er per ongeluk iets overschreven wordt of verwijderd. Dan zijn er nog geen backups, tenzij je een NAS of cloud opslag hebt met een historie functie.

Maar gebruikers slaan ook wel eens lokaal dingen op (bureaublad). Als je dan met ext4 werkt is recovery zo goed als bekeken.

Ik heb trouwens Michael Opdenacker hierover gemaild en die antwoordde dat ext2 via de ext4 driver ondersteund blijft. Moet nog testen of er een impact is op de functionaliteit.

[c-nan]

Als je in een productie omgeving perongeluk bestanden kan verwijderen waar geen backups van zijn, dan ligt daar het probleem. Niet aan het gekozen filesystem.

[Azbest]

Bedrijven handelen vaak oplossingsgericht. Je kan niet voorkomen dat er fouten worden gemaakt. Als je dan toch hulp kan bieden in zo'n situatie via een omweg (recovery) is je klant alsnog tevreden en heb je zelf waarschijnlijk een betere dag.

[c-nan]

Oké, laten we het volgende stellen:
Server 1 heeft ext2
Server 2 heeft ext4

Beide zijn I/O intensief en plots vallen de servers uit ivm een stroomstoring.

Welke server zal sneller en makkelijker recoveren? Diegene met of zonder journaling?

[fastedje]

Je kan met extra het aantal writes ook prima verminderen met de opties:
noatime
nobarier of barriers=0
https://docs.kernel.org/a...o%20the%20buffer%20cache.

Met tune2fs kan je de journal van een bestaand filtersystem ook uitzetten met de opties '^has_journal'

Als je echt het aantal writes wilt minimaliseren, gebruik dan een temps volume/ramdisk en schrijf dan alleen files die je wilt bewaren op gezette tijden naar een share of naar je flash disk.

[vanaalten]

Je hebt het stuk gemist waarin verteld wordt dat ext2 sowieso al niet veel meer gebruikt wordt?

Nee, dat heb ik niet gemist.

Maar ik vind het best een mogelijkheid dat iemand die destijds Linux op z'n systeem installeerde dat gedurende de jaren wel regelmatig een update gaf (immers is er bijzonder weinig noodzaak om een schone installatie te doen, m'n server die ik in 2002 heb geinstalleerd heeft sindsdien geen nieuwe/schone installatie gehad, enkel updates naar nieuwere Debian versies. En dan vind ik het best denkbaar dat iemand geen reden voor zichzelf ziet om van ext2 naar ext4 over te gaan, hoe makkelijk die stap ook gemaakt is.

En dan heb ik vooral zo iets van "waarom zou je mensen forceren naar ext4 over te stappen voor een probleem dat pas in 2038 speelt?". Maar nogmaals: ik vind de genomen actie dus prima. Gebruikers die nog steeds ext2 als FS hebben worden niet gedwongen om een overstap te maken, enkel een andere driver instellen.

[rbr320]

Wat ik me af vraag is waarom je op servers die je in 2002 hebt geïnstalleerd hebt gekozen voor het Ext2 filesystem en niet een journaling filesystem zoals Ext3 (dat toen al stabiel was) of XFS.

[JackBol]

Of waarom je een server uit 2002 nog altijd hebt draaien. Toen bestond SSD nog niet, en ik zou zelf geen spinning disks van 22 jaar oud meer vertrouwen.

[sus]

Die kan je natuurlijk al lang zonder issues over hebben gezet naar SSD of een nieuwe HDD. Heb hier ook een instal al jaaaaaren draaien die vanaf een oude HDD eerst naar een grotere HDD is gegaan en daarna via een sata SSD nu op een nvme draait.

De fysieke machine van destijds draait al even niet meer - die is in stappen vervangen

[Reactie gewijzigd door sus op 23 juli 2024 13:15]

[JackBol]

Waarom zou je een ext2 volume dd'en terwijl je ook gewoon het hele filesystem can rsyncen? Ik vind het echt spijkers op laag water zoeken.

[sus]

Ik reageer op je “server uit 2002” en “spinning disks”

[Blokker_1999]

Er zijn bepaalde use cases waarbij het gebruik van ext2 in die tijd werd aangeraden, bijvoorbeeld voor je /boot partitie, net omdat die beter niet journaled kan zijn.

[Bamboozled]

Dit is nog heel lang door heel veel installers tijdens auto partitionen gebruikt.

https://workaround.org/is...an-buster-on-your-server/

Ik denk dat er heel veel LTSen draaien met EXT2 "want dat moet voor je boot partitie".

Ik zet zelf alles in LVM/EXT4 ook boot. Want dat kan gewoon.

[Reactie gewijzigd door Bamboozled op 23 juli 2024 13:15]

[Cybertinus994]

En grub ondersteunde in die tijd ook alleen maar ext2

[fastedje]

Ik ben zelf niet echt fan van XFS ook al pushed RedHat dit nogal. Een probleem wat lang aanwezig was is dat open files bij een reset of crash plotseling leeg zijn. Hierdoor is mijn vertrouwen in XFS wel weg. Met ext4 heb ik nooit dit soort problemen gezien. Verder is btrfs ook interessant en lijkt ondertussen ook production grade voor de meeste features.

[rbr320]

Btrfs is inderdaad prima geschikt voor dagelijks gebruik mits je het op een enkele disk gebruikt of gebruik maakt van simpele RAID-modi zoals stripes en mirrors. RAID-modi met parity zoals RAID5 en 6 worden nog steeds afgeraden. Daarom gebruik ik al een paar jaar naar volle tevredenheid ZFS.

Het probleem wat jij beschrijft met XFS ben ik nog nooit tegenaan gelopen, wat natuurlijk niet wil zeggen dat het niet voor komt. Inderdaad is het momenteel vooral Red Hat die XFS als standaard hanteert, maar het bestandssysteem is oorspronkelijk ontworpen door Silicon Graphics, Inc. Voor zijn tijd was het zeer betrouwbaar en met goede performance.

[TheVivaldi]

Los van de andere genoemde redenen is ruim op tijd zijn altijd beter. Om maar weer de autovergelijking te maken: pas in 2035 moeten alle nieuwe auto's in de EU elektrisch zijn, maar dat betekent niet dat automerken tot kort daarvoor wachten met het uitbrengen van elektrische auto's. Je wilt er ruim op tijd bij zijn, dus als je nu al ext2 kunt uitfaseren, waarom dan niet?

[Miglow]

Oh, ik dacht in 2030 alles elektrisch. Kan ik nog 10j sparen om nog een nieuwe (hybride) benzineauto te kopen

[klakkie.57th]

geheel niet ter zake, maar toch effe dit misverstand uit de wereld helpen

De Europese Unie en Duitsland hebben aan akkoord gesloten over de verkoop van auto's met verbrandingsmotor. Ook na 2035 zal je een wagen op benzine of diesel kunnen kopen, op voorwaarde dat hij op koolstofneutrale brandstof rijdt - zogeheten e-fuels.

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 13:15]

[Amanoo]

Ik heb wel eens gehoord van Porsche die ergens een fabriek zou hebben waar ze op zonne-energie benzine maken. Maar dat is dus sowieso genoeg een ding om in de wet te zetten? Interessante ontwikkeling waar ik niet veel van weet.

[aikebah]

Weinig kans op een benzine- of diesel-auto op koolstofneutrale brandstof.

Een auto met verbrandingsmotor wellicht, maar geen benzine- of dieselauto.

[Jazco2nd]

Dankzij keiharde lobby van de Duitse auto boeren ja, die veel te lang op hun gat hebben gezeten en nu de afgrond in staren. Ongelooflijk zwak van de overheid dat ze hierheen meegaan.

Maar dat zien we ook bij de veeboeren lobby nu gebeuren. Alle plannen worden afgezwakt.

[Mellow Jack]

Forceren is een groot woord. Een kernel is geen besturingssysteem.

Als je nu een kernel uitbrengt, die het nog heeft. Die gooien ze in Ubuntu LTS met 12 jaar support. Grote kans dat je de komende jaren nog gewoon een device hebt met deze feature. 2038 is in dat opzicht redelijk in de buurt

[twiet]

En dan heb ik vooral zo iets van "waarom zou je mensen forceren naar ext4 over te stappen voor een probleem dat pas in 2038 speelt?"

Nog twee redenen om snel over te stappen:

• ext3 is journaling. Als je spanningsonderbreking hebt, duurt het checken van een ext2 filesystem veel langer dan ext3. Bij ext2 moet het hele filesysteem gecheckt worden (minuten, uren), bij ext3 alleen de journal (tienden van seconden). En ext2 is veel ouder en foutgevoeliger, want geen journal.
• het converteren van een ext2 naar een ext3 filesystem is snel gedaan. Zie https://www.linux.com/tra...rt-ext2-ext3-file-system/ als voorbeeld

[Verwijderd]

Je kunt ext2 omzetten naar ext3 door via tune2fs een journal toe te voegen, en je kunt ext3 omzetten naar ext4 door via tune2fs de ext4 features te enablen. Wat worden er een hoop woorden vuil gemaakt aan niets.
De drivers blijven backwards compatible en ext2 is zonder data verlies te upgraden naar zijn nakomelingen.

[arjan1995]

Offtopic: zit daar nog steeds dezelfde hardware in (en dus een 32 bits OS)?

[vanaalten]

Nee, meermaals geupgrade qua hardware. En qua bestandsysteem ondertussen ZFS.

Maar ik stelde ook niet dat ik ext2 gebruik of gebruikte - enkel dat ik mij kan voorstellen dat je met enkel OS updates en geen verse installaties, je lang met ext2 kan doen.

[The Zep Man]

Begrijpelijk dat ze er nu mee stoppen, het is 30 jaar oud en zelfs de 2 opvolgers zijn inmiddels al oud (ext4 was stabiel in 2008), waarvan er één zelfs compatibel is.

Leeftijd van een filesystem is geen indicator om met ondersteuning te stoppen of niet. FAT32 is 28 jaar oud, en wordt op veel moderne systemen gebruikt voor de UEFI systeempartitie. Ook FAT32 kent een opvolger (exFAT, niet backwards compatible), maar je komt er niet vanaf.

Adoptie is belangrijker. Ik ken oude ARM-systemen met een dodgy bootloader die enkel de kernel in kan laden van een ext2-partitie. Dat is met de wijziging in dit artikel geen probleem: de ext4-driver kan met een ext2-partitie werken. Er gaat dus geen functionaliteit verloren. Het enige dat gedaan wordt is redundante code opruimen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 13:15]

[arjan1995]

- Oeps, zelf te kort gelezen, je had al gezien dat de ext4 driver het ext2 filesystem nog ondersteunt.

[Reactie gewijzigd door arjan1995 op 23 juli 2024 13:15]

[GertMenkel]

Apparaten die nog puur ext2, met de oude driver, gebruiken, hadden al tien jaar geleden een upgradepad moeten opzetten.

Echter ben ik bang dat er nog een hele hoop op oude configuraties draait. Nu zal het in dit geval niet zo heel lastig zijn te migreren (aangezien de ext4-driver gewoon werkt), maar ik zou er niet van uit gaan dat dit weinig gebruikt wordt.

Aan de andere kant: oude troep die niet bijgehouden wordt, krijgt toch geen kernelupdates. Effectief is het verwijderen van de oude drivers even impactloos, maar onderschat niet hoeveel oud spul er nog draait. Y2K38 gaat een aardig probleem worden, en niet omdat de technologie er niet klaar voor is om naar 64-bit tijden te schakelen.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 13:15]

[downtime]

Y2K38 gaat een aardig probleem worden, en niet omdat de technologie er niet klaar voor is om naar 64-bit tijden te schakelen.

Ik noem dat geen probleem. Het is een kans om van oude meuk af te komen.

[MneoreJ]

Zeker, een uitgelezen kans. Moet die kans wel benut worden en niet gezien worden als iets dat alleen maar geld kost. Je wil als eindgebruiker niet terecht komen in, zeg, een of andere trein met een stuk embedded techniek dat een Y2K38 probleem heeft, want dan ben jij ineens de oude meuk geworden waar men vanaf komt.

[GertMenkel]

Ja als het de sprinklers van je buurman zijn, nee als het de controlesystemen van je energiecentrale zijn. Het ligt er maar net aan wat er kapot gaat, natuurlijk.

[downtime]

Omgekeerd: Het boeit me niet of de sprinklers van mijn buurman op totaal achterhaalde software draaien. Bij de controlesystemen van een energiecentrale vind ik alles wat hun kan dwingen om up-to-date software te draaien meegenomen.

[cricque]

"hadden al tien jaar geleden een upgradepad moeten opzetten".

Dit komt nu altijd en overal gelijk welk besturingsysteem aan de pas. Ja maar je had al lang kunnen upgraden en dergelijke. In grote organisaties doe je dit niet zomaar. Ik weet nog een overheid instantie die ging migrereren van XP naar Windows 7 als Windows 10 er al was. Dat kost allemaal tijd en geld. En als het draait waarom dan upgraden (zo denkt een manager/bedrijfsleider)

[GertMenkel]

Ja, daarom noem ik het "upgradepad" Upgraden kost snel al een paar jaar, dus daar moet je een paar jaar voor je supportcontract afloopt al mee beginnen.

[Lothlórien]

Omdat het geen journaling systeem is, is het ideaal voor kleine USB drives die je tot de max wilt vullen met data. Nu zal het echt niet vaak voorkomen dat je ext2 formateerd vanwege die paar megabytes die je dan overhoudt, maar ik heb hier denk ik ook nog wel een paar oude drives met ext2 liggen.

[DjoeC]

De eerste werkzaamheden voor Y2K werden al in de zeventiger jaren gestart. Overigens, Aan oplossingen voor Y2038 wordt ook al heel lang aan gewerkt. Vroeger, en voor een deel ook nu, werd gedacht dat software nooit zolang zou meegaan - 14 jaar is tegenwoordig toch een eeuwigheid? Maar stel je boekhoudsoftware voor. Debet-credit zal altijd blijven zoals dat nu is ofwel de kern van dat soort software hoeft niet vervangen te worden anders dan in geval van niet langer draaien op nieuwe systemen/nieuwe versies van talen. Eigenlijk geldt hetzelfde voor filesystemen: Waarom zou je die vervangen?

Hmm, dan denk ik nu aan organisaties als Nationaal Archief of Koninklijke Biliotheek die dingen voor "de eeuwigheid" moeten bewaren..... Filesystemen, conversies....

[MneoreJ]

Er zit natuurlijk een behoorlijk verschil tussen een bestandssysteem dat actief gebruikt wordt, en iets dat alleen ter archief leesbaar moet blijven. Voor dat laatste zit je met ext2 wel goed, aangezien Linux OSS is en in het uiterste geval dat er zelfs geen oude kernel met ondersteuning draaiend te krijgen is op nieuwe hardware je de driver kunt backporten. Voor dat eerste, als er geen mogelijkheid is het bestandssysteem te upgraden naar iets dat wel actief ondersteunt wordt kijk je waarschijnlijk ook aan tegen het in stand houden van een hele softwareomgeving door middel van virtualisatie, en dan maakt het ook niet uit of er in moderne kernels nu wel of geen ondersteuning is.

Zelfs dan is het geheel een behoorlijk academisch verhaal omdat de meeste software geen benul of belang heeft bij welk bestandssysteem er nu precies gebruikt wordt. Het doel van een bestandssysteem is natuurlijk gedeeltelijk ook dat de details van hoe de bestanden nu opgeslagen worden juist achter een abstractielaag zit. De kans dat je boekhoudsoftware precies ext2 vereist en met niks anders om kan gaan is dan ook te verwaarlozen.

[TheVivaldi]

Dat ook, en zelfs native kun je doorgaan. Als je alles offline houdt, dan zie ik geen reden waarom je de kernel niet gewoon op een oude versie zou kunnen houden. Met als uitzondering het YK2038-probleem natuurlijk.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 13:15]

[MneoreJ]

Belangrijkste probleem bij de kernel ook bij het oude houden is dat je de situatie kunt krijgen dat die uiteindelijk de hardware waarop je draait niet meer ondersteunt; hardware heeft tenslotte niet het eeuwige leven en zul je in tegenstelling tot software nog wel eens gedwongen moeten vervangen. Maar dan komt zoals ik al zei virtualisatie om de hoek kijken; als je software zo kritiek en onveranderlijk is wil je het geheel het liefst toch in een VM hebben.

[Verwijderd]

Dat moet uiteindelijk toch naar glas (microsoft) maar wat dag je van schrijven naar recente hardware / software, dat moet toch eens in de zoveel tijd

[downtime]

In de IT bestaat geen "eeuwigheid". Media vervaagt, technologie veroudert en kennis verdwijnt. Archiveren is niet iets passiefs, waarbij je het op de plank legt en vergeet, maar het is een actief proces. Ook een museum haalt periodiek dat schilderij van de muur en doet onderhoud en herstel omdat alleen al de blootstelling aan lucht en licht voor schade zorgt.

[Goderic]

Er zijn machines die nu geïnstalleerd worden en over 14 jaar nog draaien. Ik vind het persoonlijk nogal laat.

[MneoreJ]

Machines die nu geïnstalleerd worden gaan vrijwel zeker geen ext2 gebruiken, want het is allang niet meer de default. Je kunt er natuurlijk wel expliciet voor kiezen, maar dan weet je ook wat je je op de hals haalt. Inmiddels krijg je bij het mounten van ext2 op een modern systeem ook gewoon een waarschuwing dat timestamps na 2038 niet ondersteund worden, dus zelfs als je het niet wist kom je er hopelijk snel achter.

[MarnickS]

Maar niemand die nu een machine installeert gebruikt ext2

[latka]

Je kunt zelfs in-place upgraden van ext2 naar ext4, dus de impact hiervan is inderdaad minimaal.

[lenwar]

Je kunt zelfs in-place upgraden van ext2 naar ext4, dus de impact hiervan is inderdaad minimaal.

Dat is een gevaarlijke uitspraak. De 'dus' specifiek. Het feit dat je het in-place kan migrereren, wil niet zeggen dat het niet grote gevolgen kan hebben. Ext4 heeft uiteraard echte voordelen. (timestamping, online defragmentatie, journaling, enz.). Maar aan de andere kant heeft ext2 veel minder schrijfacties nodig voor dezelfde functionele handelingen (mede door het gebrek aan journaling), waardoor het voor flashgeheugen echt een betere oplossing kan zijn.

Het ligt er dus heel erg aan hoe en waarom iemand op dit moment nog op ext2 zit.

Edit: "Mede" toegevoegd bij gebrek aan journaling door reacties van @ookhoi en @MneoreJ Thanks

[Reactie gewijzigd door lenwar op 23 juli 2024 13:15]

[MneoreJ]

Die journaling is niet echt een sterk argument; je kunt ook een ext4 systeem gebruiken zonder journaling (-O ^has_journal). Daarnaast is ook ext2 natuurlijk niet specifiek ontworpen voor flash; als je echt het aantal schrijfacties wil beperken kun je beter een dedicated oplossing als F2FS gebruiken.

Wil niet zeggen dat ext2 echt geen bestaansrecht meer heeft (het soort hardware dat flash heeft ondersteunt misschien niks beters) maar het gaat toch wel steeds meer richting "alleen oude brol/legacy" toe.

[ookhoi]

Maar aan de andere kant heeft ext2 veel minder schrijfacties nodig voor dezelfde functionele handelingen (door het gebrek aan journaling)

ext4 kan ook zonder journal aangemaakt worden:

mkfs.ext4 -O ^has_journal /path/naar/device/

[Stroper]

Voor ext speelt dit inderdaad niet zo een grote rol, aangezien de drivers backwards compatible zijn.

Maar toch liever ruim op tijd dwingen over te stappen, dan veel te lang te wachten.
ext4 is er al sinds 2008, ext3 sinds 2001
De mensen hebben dus al ruim de tijd gehad om over stappen naar iets nieuws.
Even wachten met upgraden om te kijken of het stabiel is, is zeker verstandig op productieomgevingen.
Maar het andere uiterste(Zoals de Duitste Spoorwegen die in 2024 op zoek moesten naar een Windows 3.11 specialist) zie ik helaas veel te vaak in de IT.

[MneoreJ]

Naja, de kans dat er tussen nu en 14 jaar geen enkele gelegenheid gaat komen om een nieuw bestandssysteem in te richten en je je storage op die laag nooit vervangt is natuurlijk niet heel groot. Kan in theorie natuurlijk wel, als je een dik RAID systeem hebt dat ship-of-Theseus stijl altijd up is gebleven met alleen maar nieuwe drives, maar gegeven de voordelen van ext3 en zeker de journaling van ext4 had je inmiddels eigenlijk wel wat tijd mogen steken in upgraden. Als je een systeem hebt dat in 14 jaar geen downtime kan tolereren mag je inmiddels misschien sowieso ZFS overwegen in plaats van ext2...

Dit alles is natuurlijk sowieso academisch omdat inderdaad, zoals vermeldt, de ext4 driver ook met ext2 overweg kan. En zelfs dan is het nog niet 100% gezegd dat de ext2 driver echt weg zou moeten, aldus Ted Ts'o:

Well, if we *cared* we could backport the support for the expanded timestamps to ext2. I'm not sure it's worth the effort, but it's not that hard....

[SSH]

Ik heb nog EXT2 disks want archieven. Toch maar eens omzetten dan

[Blorgg]

Ik heb nog EXT2 disks want archieven. Toch maar eens omzetten dan

De ext4 driver ondersteunt ext2. Als je een oude ext2 disk aan een nieuw systeem met kernel 6.9 hangt dan werkt dat gewoon. Hoef je niets voor te doen verder.

[TheVivaldi]

Dat wel, maar er zitten wel beperkingen aan ext2, zoals YK2038, dus omzetten kan lonend zijn.

[MSalters]

Ook na 2038 kun je nog files van een ext2 partitie lezen. Dan moet je wel "atime" (access time) uitzetten.

[fcambron]

Kleine opmerking: Unix tijd wordt gestockeerd in een 32 signed integer. Tijd 0 is 01-01-1970.
2^31 seconden is iets meer dan 68 jaar. De minium tijd is vrijdag 13/12/1901, de maximum dinsdag 19/1/2038. Meer info op Wiki Pagina

[xorpd]

De makkelijkste oplossing voor het 2038 probleem is dan ook (volgens Linus zelf) "move the epoch", oftewel negatieve timestamps verwijzen naar na 2038 i.p.v. voor 1970. Hiermee kunnen we nog door tot 2106.

[Reactie gewijzigd door xorpd op 23 juli 2024 13:15]

[MSalters]

"Epoch" is het moment waarop time_t=0 gebeurde. Dat is dus 1970-01-01. Dat verandert niet wanneer je de 32ste bit van time_t interpreteert als plus 2 miljard in plaats van min twee miljard. Nul blijft nul.

[xorpd]

Je verplaatst de epoch dus naar 2106 voor negatieve getallen, of je interpreteert het als een unsigned int. Beide komen op hetzelfde neer. Negatieve timestamps zijn toch niet in gebruik.

[beerse]

Gelukkig wordt de soep niet zo heet gegeten als ze wordt opgediend: Dat de kernel zelf geen ext2 driver aan boord heeft houdt in dat ze een uitdaging heeft om van ext2 te booten. Voor zover beschreven kan de ext4 driver wel met ext2 om gaan dus dat moet geen probleem zijn.

En de gemiddelde linux distributie kan met heel veel nog veel oudere en exotischere bestandssystemen overweg, dat ext2 niet veel gebruikt zou worden is voor linux in haar geheel geen reden om de ondersteuning helemaal uit te zetten. Het is dat het niet meer rechtstreeks in de kernel zit.

Voor de liefhebbers: https://en.wikipedia.org/wiki/List_of_file_systems
toevoeging, nog leuker: https://en.wikipedia.org/wiki/Comparison_of_file_systems

[Reactie gewijzigd door beerse op 23 juli 2024 13:15]

[lkruijsw]

Voor mensen die denken dat 2038 nog heel erg ver weg is, het hangt af van de situatie.

Als je het puur of software hebt die je zelf onder beheer hebt, dan ja, dan is het nog ver weg.

Maar als je een product uitlevert naar anderen en er is geen zekerheid dat de klant upgrades doet, dan komt het akelig dichtbij. Als je wilt dat het product 10 jaar mee gaat, dan moet het in 2028 dus allemaal okay zijn. Dat is nog maar 4 jaar!

[kabelmannetje]

Jemig wat een geschiedenis al! Kan mij nog goed herinneren dat ik RedHat met ext2 intalleerde. En wat was dat beter dan windows95! Goed te zien dat EXT nog steeds in ontwikkeling is, ook al is deze de-facto standaard van destijds door andere filesystems als btrfs overgenomen.

[gwayne]

En ik altijd maar denken dat de ext3 driver ook ext2 ondersteunde zonder logs.

[latka]

Ik dacht dat de ext3 driver al eruit was, maar idd. je kunt ext2 mounten met de ext4 driver (met beperkingen zoals geen journal uiteraard en dus waarschijnlijk ook het 2038 probleem).

[Dubbeldrank]

Klopt, en de ext4 driver ook. Je kan je ext2 bestandsysteem gewoon blijven gebruiken.