Nachdem man sich einige Zeit den Code für verschiedene Dienstprogramme und den Kernel-Code angesehen hat, scheint es, dass das, was @Hauke vorgeschlagen hat, wahr ist - ob ein Dateisystem ext2/ ext3/ ext4nur durch die aktivierten Optionen definiert ist.
Von der Wikipedia-Seite auf ext4:
Rückwärtskompatibilität
ext4 ist abwärtskompatibel mit ext3 und ext2, sodass ext3 und ext2 als ext4 gemountet werden können. Dies wird die Leistung geringfügig verbessern, da bestimmte neue Funktionen von ext4 auch mit ext3 und ext2 verwendet werden können, z. B. der neue Blockzuweisungsalgorithmus.
ext3 ist teilweise vorwärtskompatibel mit ext4. Das heißt, ext4 kann als ext3 gemountet werden (wobei beim Mounten "ext3" als Dateisystemtyp verwendet wird). Wenn die ext4-Partition jedoch Extents verwendet (eine wichtige neue Funktion von ext4), geht die Fähigkeit zum Mounten als ext3 verloren.
Wie höchstwahrscheinlich bereits bekannt ist, besteht eine ähnliche Kompatibilität zwischen ext2und ext3.
Nachdem ich mir den Code angesehen hatte, blkidmit dem verschiedene extDateisysteme unterschieden werden , konnte ich ein ext4Dateisystem in etwas verwandeln , das als ext3(und von dort bis ext2) erkannt wurde . Sie sollten dies wiederholen können mit:
truncate -s 100M testfs
mkfs.ext4 -O ^64bit,^extent,^flex_bg testfs <<<y
blkid testfs
tune2fs -O ^huge_file,^dir_nlink,^extra_isize,^mmp testfs
e2fsck testfs
tune2fs -O metadata_csum testfs
tune2fs -O ^metadata_csum testfs
blkid testfs
./e2fsprogs/misc/tune2fs -O ^has_journal testfs
blkid testfs
Erste blkidAusgabe ist:
testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" SEC_TYPE="ext2" TYPE="ext4"
Zweitens ist:
testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" SEC_TYPE="ext2" TYPE="ext3"
Und der letzte:
testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" TYPE="ext2"
Beachten Sie, dass ich eine neue Version von verwenden musste, die e2fsprogsin meiner Distribution verfügbar war, um die metadata_csumFlagge zu erhalten. Der Grund für das Setzen und anschließende Löschen war, dass ich keine andere Möglichkeit gefunden habe, das zugrunde liegende EXT4_FEATURE_RO_COMPAT_GDT_CSUMFlag zu beeinflussen . Das zugrunde liegende Flag für metadata_csum( EXT4_FEATURE_RO_COMPAT_METADATA_CSUM) und schließen EXT4_FEATURE_RO_COMPAT_GDT_CSUMsich gegenseitig aus. Durch das metadata_csumDeaktivieren EXT4_FEATURE_RO_COMPAT_GDT_CSUMwird metadata_csumdas letztere deaktiviert , aber durch Deaktivieren wird letzteres nicht wieder aktiviert.
Schlussfolgerungen
Mangels tiefer Kenntnisse über die Interna des Dateisystems scheint es entweder:
Die Journal-Prüfsumme soll ein definierendes Merkmal eines Dateisystems sein, das so erstellt wurde, ext4dass Sie es eigentlich nicht deaktivieren sollten, und die Tatsache, dass ich dies verwaltet habe, ist wirklich ein Fehler e2fsprogs. Oder,
Alle ext4Funktionen wurden immer so konzipiert, dass sie deaktiviert werden. Wenn Sie sie deaktivieren, wird das Dateisystem in jeder Hinsicht zu einem ext3Dateisystem.
In beiden Fällen ist ein hohes Maß an Kompatibilität zwischen den Dateisystemen eindeutig ein Entwurfsziel. Vergleichen Sie dies mit ReiserFS und Reiser4, bei denen Reiser4 eine vollständige Neugestaltung darstellt. Was wirklich zählt, ist, ob die vorhandenen Funktionen von dem Treiber unterstützt werden, der zum Mounten des Systems verwendet wird. Wie der Wikipedia-Artikel feststellt, kann der ext4Treiber auch mit ext3und verwendet ext2werden (tatsächlich gibt es eine Kernel-Option, um den ext4Treiber immer zu verwenden und die anderen loszuwerden). Das Deaktivieren von Funktionen bedeutet lediglich, dass die früheren Treiber keine Probleme mit dem Dateisystem haben und es daher keine Gründe gibt, sie daran zu hindern, das Dateisystem bereitzustellen.
Empfehlungen
Es scheint am besten zu sein, zwischen den verschiedenen extDateisystemen in einem C-Programm zu unterscheiden libblkid. Es ist Teil von util-linuxund dies ist, was der mountBefehl verwendet, um zu versuchen, den Dateisystemtyp zu bestimmen. Die API-Dokumentation finden Sie hier .
Wenn Sie die Prüfung selbst durchführen müssen, müssen Sie dieselben Flags testen, dielibblkid der richtige Weg zu sein scheinen. Obwohl in der verknüpften Datei insbesondere das EXT4_FEATURE_RO_COMPAT_METADATA_CSUMFlag nicht erwähnt wird, das in der Praxis getestet zu werden scheint.
Wenn Sie wirklich das ganze Schwein gehen wollten, könnte das Suchen nach Journal-Prüfsummen eine todsichere Möglichkeit sein, um herauszufinden, ob ein Dateisystem ohne diese Flags vorhanden ist (oder war ) ext4.
Aktualisieren
Es ist tatsächlich etwas einfacher, in die entgegengesetzte Richtung zu gehen und ein ext2Dateisystem zu fördern, um ext4:
truncate -s 100M test
mkfs.ext2 test
blkid test
tune2fs -O has_journal test
blkid test
tune2fs -O huge_file test
blkid test
Die drei blkidAusgaben:
test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" TYPE="ext2"
test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" SEC_TYPE="ext2" TYPE="ext3"
test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" SEC_TYPE="ext2" TYPE="ext4"
Die Tatsache, dass ext3/ ext4features auf einem Dateisystem, das ursprünglich gestartet wurde, so einfach aktiviert werden kann, ext2ist wahrscheinlich die beste Demonstration dafür, dass der Dateisystemtyp tatsächlich durch die Features definiert wird.