Az ext3 fájlrendszer driver kódjának eltávolítását fontolgatják a Linux kernelfejlesztők

Fájlrendszer, NAS, storage

A SUSE alkalmazásában álló Jan Kara a napokban arra kérte Linus-t, hogy pull-olja a legfrissebb változásokat az Ext2/3, UDF, quota fájából. A kérés mellé megjegyezte, hogy e pull legnagyobb változtatása az ext3 fájlrendszer driver eltávolítása (körülbelül 28 ezer kódsort érint). Linus óvatosan közelítette meg a kérést. Tudni szerette volna, hogy valóban biztonsággal (regresszió nélkül) eltávolítható-e az ext3 driver a kernelfából. Többen, köztük Theodore Ts'o biztosították Linust, hogy probléma nélkül eltávolítható a driver, hiszen annak funkcionalitását rég átvette az ext4 driver.

A teljes szál itt kezdődik.

( mauzi v | 2015. 09. 02., sze – 14:15 )

TL_DR... Az ext4 kód tud stabilan ext3-at mountolni? Amikor azt mondom, hogy "mount -t ext3..." akkor az az ext3 kódot hozza, vagy az ext4 kódot kompatibilitási módban?

"The ext4 code can read and write ext3 filesystems without any compatibility issues (i.e. none of the ext4-specific features are enabled automatically) and have been doing so for all RHEL and SLES users for the past several years via the CONFIG_EXT4_USE_FOR_EXT23 option (added in commit 24b58424 in 2009). It looks like the same for Ubuntu since early 2014 also.

The ext4-specific features either need to be enabled specifically via tune2fs (if possible) or at mkfs time."

és

"Both Red Hat and SuSE, as well as Debian and Ubuntu, are using ext4 with CONFIG_EXT4_USE_FOR_EXT23 for a couple of years now to support ext2 and ext3 file systems."

Vagyis már rég az ext4-et használjuk az ext3-hoz jó ideje.

--
trey @ gépház

Amikor (réges-régen) a Nexus One-n cyanogen-t frissítettem és főverzió ugrás volt elkezdte valamelyik fájlrendszert ezzel az ext4 compat móddal mountolni. Nem lehetett a képernyőt feloldani, mert mire a képernyő felébredt már le is járt a timeout, 100% system-ben volt a CPU a lassú fájlrendszer miatt. Átállítottam, hogy explicite ext2-ként mountolja és minden probléma megoldódott.

Ennek a döntésnek csak akkor lenne igazán értelme, hogyha az ext4 supportot is eltávolítanák. Tennének vele egy nagy szívességet.

Amúgy meg a RedHat se javasolja hogy bármelyik fájlrendszer backward-compatible módban legyen használva.

Nem lehet, hogy valamit félreértettél? Attól, hogy explicit megadod, hogy ext2-ként mount-oljon, még továbbra is az ext4 driver lesz használatban, mivel manapság ez a modul felel az ext2, ext3, ext4 filerendszerekért. Persze be lehetne tölteni kifejezetten az elöregedő modulokat, amelyeket éppen most készülnek kitenni a kernelből, mert már semmi szükség rájuk.

Ennek a döntésnek csak akkor lenne igazán értelme, hogyha az ext4 supportot is eltávolítanák.

Miért kellene eltávolítani az ext4 supportot? Annak mi értelme, hogy az ext4 driver kezeli az ext2-t, ext3-at, de ki tudja, milyen módon nem engedjük meg neki az ext4 kezelését?

Fedorán 4.1.6-os kernelben a releváns konfig:

# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

3.14-ben még van, a kisgépen ezt használom.
Mivel a kisgépen nincs ext4-es fájlrendszer, ezért a használt kernelbe be sincs fordítva ext4.
ext3 van modulban szükség esetére, mert a külső vinyókon az van, ha netán rá kell kötni valamelyiket.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Igen, és nem is olyan egyszerű tőle megválni.

"> I think also that we should remove the ext2 driver before we remove the ext3
> driver.

Very strong disagreement here. Compare to ext4 and ext3, ext2 is a very
different beast with a different architecture. It's basically our
template for "simple" file system drivers, and very useful for that
alone, nevermind for all the systems that don't want a complicated
journaling or log based file system for various reasons."

[...]

"A vast majority of Android smartphones in the
wild use ext2, as do a very significant portion of embedded systems that
don't have room for the few hundred kilobytes of extra code that the
ext4 driver has in comparison to ext2."

--
trey @ gépház

( log69 | 2015. 09. 02., sze – 19:26 )

Mi az a késztető ok, ami miatt ennyire el kell távolítani? Millió driver-t tartalmaz a kernel amit karban tartanak, és pont ilyen fontos dolgot akarnak kidobni? Sokan unatkoznak ott is úgy látom.

Minden lényeges be van linkelve:

"The main rationale is that two code bases is harder to support than
one. When bugs get fixed in ext4, they don't necessarily get
back-propagated to ext3 except for a manual process where Jan notices
that a bug fixed in ext4 is also in ext3, and he manually ports the
patch over.

Both Red Hat and SuSE, as well as Debian and Ubuntu, are using ext4
with CONFIG_EXT4_USE_FOR_EXT23 for a couple of years now to support
ext2 and ext3 file systems. So with the exception of some really
ancient enterprise Linux distros, and people who are manually
configuring their systems, very few people are likely using ext3 code
base, which means the chances that it bitrots increases. Basically,
it's only been Jan's tireless work that has kept that from happening,
given that all of the major distro's have been using ext4 to support
ext2 and ext3 file systems."

--
trey @ gépház

Őszintén szólva, ebben nem vagyok biztos. A Maturity ebben az esetben ugye futott óra, vagy megmozgatott blokkok száma. És mivel egyre több a gép, és az adat, el tudom képzelni hogy az ext4 kódban több "kilóméter" van, mint az ext3 kódban.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch