ext2 für /boot zu alt?

[slandail]

Hallo,
diesem Artikel
https://www.heise.de/news/Linux-6-9-mit ... 16942.html

und der Suche hier zu ext2 folgend ist die Nutzung von ext2 obsolet.
Frage:
Werden die Installationsmedien dementsprechend auch angepasst auf ext4 oder muss hier händisch nachgebessert werden?

[reox]

Soweit ich das in Erinnerung habe verwendet der Installer schon lange ext4. ext2 wurde vor einigen Installerversionen maximal für /boot verwendet, aber auch dort wird per-default glaube ich auch schon ext4 verwendet.

[MSfree]

ext2 wurde vor einigen Installerversionen maximal für /boot verwendet,

ext3 wurde vor über 22 Jahren eingeführt, und ext4 gibt es ja nun auch schon seit über 15 Jahren.

Meiner Schätzung nach, dürfte ext2 schon seit mindestens 20 Jahren nicht mehr als Default angeboten werden. Man konnte es aber manuell noch immer auswählen.

Da muß also fast nichts am Installer angepaßt werden, außer, daß die manuelle Auswahl von ext2 gestrichen werden muß.

[slandail]

Danke für eure Rückmeldungen.

ich habe mich aber ungenau ausgedrückt und den Titel oben konkretisiert auf ein /boot

Die letzte Neuinstallation mit einer frisch gezogenen NetInstall.iso nach einem SSD-Wechsel im Januar ergab für /boot eine ext2- Partionierung.
Hieraus ergab sich meine Unsicherheit und Nachfrage hier.

[Meillo]

Es stellt sich die Frage, worin ext3 und ext4 besser sind als ext2.

ext3 bietet als Vorteil gegenueber ext2 in erster Linie Journaling. D.h. es ist robuster bei Abstuerzen, um Daten zu recovern und das Dateisystem konsistent zu halten. Bei einer Partition wie /boot, die quasi nie geschrieben wird, sich also eigentlich nie aendert, ist das irrelevant.

ext4 bietet hoehere Limits fuer Dateien, bessere Performance bei grossen Dateien, usw. ... wiederum nichts, was fuer /boot relevant waere.

All diese ext3- und ext4-Features haben natuerlich auch ihre Kosten. Wenn man sie nicht braucht, kann man sich sowohl die Features als auch ihre Kosten sparen.

Das koennen Gruende sein, warum fuer /boot weiterhin ext2 verwendet wird.

(Fuer andere Partitionen wie /, /home, /usr, /var, usw. machen die Features von ext3 und ext4 Sinn und ihre Kosten sind vernachlaessigbar gegenueber den Vorteilen.)

[slandail]

Ich verstehe.

Dann bleibt es also für /boot bei ext2 und /home pp. bei ext4?

Vielen Dank für eure Zeit.

[reox]

Ok ich sollte vllt mal nen Installer in einer VM booten... Mein letzter Stand war das für /boot ebenfalls kein ext2 mehr verwendet wird. Kann aber auch sein, dass ich irre, weil ich die Partitionierung selten vom Installer machen lies.
Meine Information von etwa 2010 herum war, dass ext3 Support in GRUB nicht gut war und man daher ext2 verwenden sollte/musste. Die Erklärung von Meillo macht aber auch Sinn.

[mampfi]

Ich hab noch zwei ext2-Partitionen in Betrieb, eine mit 1 GB und eine mit 5 GB, wenn ich aber jetzt so nachdenke, so ändert sich nur auf der mit 1 GB öfter was.

root und home sind ext3.

Und minix nutze ich schon sehr lange nicht mehr

(Hab mich gerade selbst ein bißchen aufgezogen)

[kreuzschnabel]

Meine /boot-Partition ist auch ext2. Stabil wie ein Granitblock und kann alles, was es dafür muss.

Das ist auch schon die einzige extendete, der Rest ist btrfs

--ks

[MSfree]

Die letzte Neuinstallation mit einer frisch gezogenen NetInstall.iso nach einem SSD-Wechsel im Januar ergab für /boot eine ext2- Partionierung.

Ich kann mich nicht erinnern, jemals in den letzten 20 Jahren ext2 für irgendeine Partition vorgegeben bekommen zu haben. Da wurde mir schon ewig mindestens ext3 oder ext4 vorgegeben, auch für die /root-Partition.

Wenn man da wirklich ext2 wollte, mußte man das mutwillig auswählen.

[slandail]

Alles klar - besten Dank

[cosinus]

Meine /boot-Partition ist auch ext2. Stabil wie ein Granitblock und kann alles, was es dafür muss.

Von dem Y2038-Problem bei ext2 hast du aber schon gelesen?

[Meillo]

Meine /boot-Partition ist auch ext2. Stabil wie ein Granitblock und kann alles, was es dafür muss.

Von dem Y2038-Problem bei ext2 hast du aber schon gelesen?

Kann man dann ja einfach innerhalb der naechsten 13 Jahre mal nach ext3 konvertieren.

Wobei mich in dem speziellen Fall von /boot interessieren wuerde, inwiefern der Timestamp-Overflow ueberhaupt relevant ist. Insofern man die Inode-Timestamps nie auswertet, ist doch egal ob sie auf 1970 oder 2038 stehen und die Datumssortierung vielleicht nicht passt. Da nur der Bootloader in /boot arbeitet, ist das eine ueberschaubare Menge an Code, die geprueft werden muss. (Ich sehe derzeit auch nicht, inwiefern Zeitstempel in dem Kontext ueberhaupt relevant sind.)

Als generelles Problem von ext2 sehe ich ich den 32-Bit-Timestamp-Overflow schon, aber im speziellen Fall /boot wuerde mich interessieren, inwiefern es schlimm waere, wenn er passiert.

[MSfree]

Von dem Y2038-Problem bei ext2 hast du aber schon gelesen?

Durch Nutzung von unsigned int wäre es ein Y2106-Problem.

Im Grunde ist es aber ein Sturm im Wasserglas. 2038 ist noch lange hin, als vorläufigen Workaraound könnte man unsigned int nutzen und Hardware lebt auch nicht ewig. Irgendwann hat man neue Hardware und installiert frisch. Alte Backupplatten mit ext2 kann man auch in Zukunft noch mit dem ext4-Modul mounten, so daß der Zugriff auf alte Partitionen auch in Zukunft garantiert ist.

Ich weine ext2 keine Träne mehr hinterher und dank ext4 gibt es auch einen leistungfähigen und genauso robusten Nachfolger.

[cosinus]

Im Grunde ist es aber ein Sturm im Wasserglas. 2038 ist noch lange hin,

Das schon, aber es ja nun wirklich einfach, das Problem zu beheben und künftig einfach auf ext4 oder andere Dateisysteme zu setzen. Und 13,5 Jahre gehen schneller rum als man denkt. Denk mal 13,5 jahre zurück, da hatten wir Anfang 2011 und konnten kaum das Release von Debian 6 erwarten

[Meillo]

Von dem Y2038-Problem bei ext2 hast du aber schon gelesen?

Durch Nutzung von unsigned int wäre es ein Y2106-Problem.

``Waere'' hilft hier nicht, wenn der Timestamp als signed int umgesetzt/definiert ist. Jedenfalls fuehrt die Wikipedia das Maximaldatum im Jahr 2038 an.

Wenn man das Dateisystemmodul fuer ext2 auf unsigened int umstellt, dann gewinnt man damit rund 70 Jahre. Das ginge ohne die Daten bzw. die Inodes selbst anzufassen und waere sogar kompatibel mit signed int Implementierungen. Nicht anders wird das Mounten eines ext2-Dateisystems mittels des ext4-Moduls funktionieren. Es geht hier nur um die *Interpretation* der gespeicherten Bitfolge.

Aber nach dem Jahr 2106 kann dann in der Inode kein groesseres Datum mehr gespeichert werden, weil das Feld nicht mehr Platz hat. Da hilft dann kein anderes Dateisystemmodul, sondern man muss andere Inodes, mit mehr Platz fuer das Datumsfeld verwenden ... was bedeutet, das Dateisystem zu konvertieren.

[wanne]

Zuerst mal möchte ich anmerken, das ext3/ext4 ja nur ext2 mit Zusatzfeatures sind. Alle bleiben abschaltbar. – So wie schon ext2 viele abschaltbare features hatte. Aber sobald man ein Feature anschaltet, dass es nur in ext4 gibt ist es halt ein ext4. Deswegen ist es problemlos möglich ein ext2 als ext4 zu mounten aber nicht umgekehrt.

Wenn man das Dateisystemmodul fuer ext2 auf unsigened int umstellt, dann gewinnt man damit rund 70 Jahre.

Du verlierst auf der anderen Seite auch 70. Ist halt eventuell unwahrscheinlich, dass du Daten von vor 1970 hast.

Hardware lebt auch nicht ewig. Irgendwann hat man neue Hardware und installiert frisch.

Ich glaube nicht, dass hier irgend jemand Hardware von vor 22 Jahren verwendet. Das ist eher für Leute wie mich relevant, die ihr Dateisystem halt von Hardware zu Hardware tragen. Aber trotzdem hast du recht: Ein Sturm im Wasserglas: Defakto wir eh jeder sein Dateisystem schon lange als ext3 mounten.

Wobei mich in dem speziellen Fall von /boot interessieren wuerde, inwiefern der Timestamp-Overflow ueberhaupt relevant ist. Insofern man die Inode-Timestamps nie auswertet, ist doch egal ob sie auf 1970 oder 2038 stehen und die Datumssortierung vielleicht nicht passt.

Naja. Das problem ist halt vor allem, wenn du ein update fährst und das Datum nicht rein schreiben kannst. Klar: Du kannst an der Uhr drehen und ein falsches rein schreiben. Aber jetzt sämtliche software anpassen nur damit man ein Problem behebt, dass man einfach beheben kann, indem man einfach den Dateisystem-Treiber benutzt der seit 22 Jahren das Problem behoben hat. Daneben würde ich fast wetten, dass update-grub irgend wo Daten auswertet.

Bei einer Partition wie /boot, die quasi nie geschrieben wird, sich also eigentlich nie aendert, ist das irrelevant.

Es kostet aber auch absolut nichts, so lange nicht geschrieben wird. Da updates eh im Hintergrund laufen, verstehe ich nicht, warum man da jetzt Schreibperformance raus holen soll. Bevor ich Journaling abschalte, würde ich eher extended atributes, 32Bit UIDs, Dateien über 2GB etc. abschalten. Alles in ext2 drin und wirklich das brauchst du wirklich nicht.

All diese ext3- und ext4-Features haben natuerlich auch ihre Kosten. Wenn man sie nicht braucht, kann man sich sowohl die Features als auch ihre Kosten sparen.

Ich sehe die gar nicht: Ich nehme mal an, dass hier keiner einen Kernel ohne ext4-Support compiliert. Das ext2 Mudul wird genau so sang und klanglos aus dem Kernel verschwinden wie einst das ext3 Modul. – Hat auch keiner gemerkt. Kann man ja als ext4 mounten.

[GregorS]

All diese ext3- und ext4-Features haben natuerlich auch ihre Kosten. Wenn man sie nicht braucht, kann man sich sowohl die Features als auch ihre Kosten sparen.

Wie ich es verstehe, meinst Du mit Kosten so etwas wie Systemlast, richtig?

[Meillo]

All diese ext3- und ext4-Features haben natuerlich auch ihre Kosten. Wenn man sie nicht braucht, kann man sich sowohl die Features als auch ihre Kosten sparen.

Wie ich es verstehe, meinst Du mit Kosten so etwas wie Systemlast, richtig?

So in der Art. In dem Fall ist es eher die Komplexitaet (Potenzial fuer Bugs, Schwierigkeit das System zu verstehen, ...), die ich als Kosten sehe. Rechenleistung ist mir meist recht egal. Der hoehere Platzbedarf ist hier auch nicht relevant. Ich wollte auch gar nicht so sehr auf die Kosten abheben, weil sie in dem Fall klein sind und keinen Hinderungsgrund darstellen sollten. Mir war nur wichtig, diesen Gedanken darzulegen, weshalb man im Fall von /boot zu dem Ergebnis kommen kann, dass ext2 keine schlechte Wahl ist. (Ohne sagen zu wollen, dass man ext2 fuer /boot verwenden sollte. Ich denke bei /boot ist das Dateisystem sehr egal, solange der Bootloader es unterstuetzt.)

[Meillo]

Wenn man das Dateisystemmodul fuer ext2 auf unsigened int umstellt, dann gewinnt man damit rund 70 Jahre.

Du verlierst auf der anderen Seite auch 70. Ist halt eventuell unwahrscheinlich, dass du Daten von vor 1970 hast.

Da hast du recht. Mir war nicht bewusst, dass man auch negative Timestamps nutzen kann. (Wie sinnvoll das im Dateisystem fuer ctime, mtime, atime ist, sei mal dahingestellt.) Damit ziehe ich meine Aussage zurueck.

[wanne]

Wie sinnvoll das im Dateisystem fuer ctime, mtime, atime ist, sei mal dahingestellt.)

Das Dateisystem erschien 1992 als noch viele "echte" UNIX-Tools unterwegs waren. Zumindest 1969 könnte da mal zumindest al ctime dabei gewesen sein.

[reox]

Ich hab gerade mal 12.5.0 netinstall in einer VM gestartet.
Wenn man guided-full macht, bekommt man genau eine ext4:


Erstellt man sich manuell eine /boot Partition ist der Default dort auch ext4:


Wäre alsom eigentlich spanned zu wissen wo welcher Installer noch eine ext2 vorschlägt. Ich bin mir ziemlich sicher, dass es zu Zeiten von etch noch so war (gut das könnte man jetzt auch einfach ausprobieren )

[slandail]

KLASSE!
Genau das ist es, was ich haben wollte, diese Schaubilder/Erklärung.

Ich hatte mit einem iso zu 12.1 neu installiert und bekam eine ext2-Partition für /root

Gut, dass ich noch Zeit habe, neu zu installieren oder zu frickeln.

[rhHeini]

Ich hatte mit einem iso zu 12.1 neu installiert und bekam eine ext2-Partition für /root

Es gibt einen Weg dahin: man mache bei Devuan ein Expert-Installation. Dann überspringe man den Punkt "Zusätzliche Installer-Module laden", dann hat man nur einen ganz einfachen Installer der kein z.B. ext3/4 kann.

Edith: war der Annahme dass sich Debian- und Devuan-Installer so ziemlich gleichen. Das ist nicht (mehr) der Fall. Bei der Installation von 12.5 in einer VM zeigt sich dass der Debian-Installer immer die Basismodule läd, und damit auch ext3/4-Unterstützung, das kann man da nicht mehr überspringen wie bei Devuan.

[Meillo]

Ich hatte mit einem iso zu 12.1 neu installiert und bekam eine ext2-Partition für /root

Es gibt einen Weg dahin: man mache ein Expert-Installation. Dann überspringe man den Punkt "Zusätzliche Installer-Module laden", dann hat man nur einen ganz einfachen Installer der kein z.B. ext3/4 kann.

Sicher? Wie kann ein Installer heutzutage kein ext4 koennen!?