A Linux 6.9-cel "deprecated" jelzőt kap az EXT2 fájlrendszer driver

Nagyjából a kezdetek óta a Linux kernellel együtt élő EXT2 fájlrendszer "deprecated" státuszba kerül a 6.9-es kernel kiadásával. Ennek oka leginkább, hogy meggyűlik a baja a Y2038 problémakör.

Részletek itt.

Hozzászólások

popcorn elő 

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

Hogy repül az idő - és változnak a preferenciák:

- "...A Hungarian Unix Portal, röviden HUP[1] a legnagyobb magyar nyelvű UnixLinuxBSD és egyéb Unix-szerű operációs rendszerekkel foglalkozó weboldal, amely körülbelül 2000 óta szolgálja a magyar UNIX közösséget..."

https://hu.m.wikipedia.org/wiki/Hungarian_UNIX_Portal

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

a notebookomon a /boot ext2 brühühühü :))

Azert mert nem verziofetisisztak, hogy azonnal kivagjanak valamit. De az ext2 az ugyanaz mint az ext3 csak journaling nelkul (leegyszerusitve, mert azert van meg jo sok feature es hozzaadott ertek az ext3-ban) az ext4 meg ugyanaz mint az ext3, csak meg tobb feature-el (multiblock allocation, delayed allocation, journal checksum. fast fsck, stb stb). Szoval inkabb arrol van szo hogy tenyleg nincs szukseg az ext2-ra ha ki tudod kapcsolni az ext4-ben a nem kello feature-oket hogy ext2-nek mondja magat

Amugy is van a kernelben jo sok dolog ami vagy 30+ eves technologia es szinte senki sem hasznalja es megis benne van. Majd egyszer kiszedik ha valakit zavar. Ha meg nem akkor elfer ott a sok-sok module kozott amig van aki gondozza es utanahuzza a dolgokat benne (lehget hot pont csak neki kell egy embernek, de ez az opensource szabadsaga).

Bevallom őszintén, hogy ezt én se értem. Szerintem csak elfelejtették kivenni, vagy bent hagyták egy időre, mert kisebb komplexitású, mint az ext4 driver, és beágyazott eszközökhöz meg retrósoknak azt hitték még jó lesz erőforrást spórolni. Most meg valaki rájött, hogy túl sokáig nem nyúlt hozzá senki az ext2 kódhoz, így nem tudják vállalni érte a felelősséget, hogy nincs benne valami súlyos regresszió, bug, sérülékenység, stb..

Mindegy, most ilyen világ van, mindent be akarnak szüntetni, 32 bites támogatást (több mainstream disztró már meg is lépte, és már az x86_64-level3 megkövetelését feszegetik), X szervert, ext2 és reiserfs drivereket, stb.. Ez lassan már ilyen általános soydev mánia, hogy mindent be kell tiltani, el kell avultatni, ami nem a legújabb, és csak a legújabb fejlesztéseket kell erőltetni, mindenkit kényszerrel átterelni Waylandre, Pipewire-re, ahogy az a systemd-vel is történt, meg mindent Rust-ban, JS-ben, stb. írni, mert a C, C++ nem menő, nem memory safe, életveszélyes, elvisz a mentő, ha megpróbálod. A Python 2.x-et, Gtk1-2-őt, Qt3-4-et is elavultatták már rég. Lassan már a natív csomagokat is elavultatják, mindennek Flatpak-nek meg Snap-nek kell lenni, meg mindennek konténerben, virtualizálva, meg sandboxolva, immutable disztróként kell futni.

Nem csak a Linux, a MS is már a Win11-gyel ezt a követ fújja, 32 bit kivezetése, TPM, secure boot, megemelt procikövetelmények (már az 1. genes Threadriper is elavult szerintük, mert megette a teljesítményét a Meltdown, Specre, stb. foltjai), Win7-8.1 támogatásának vége, a Win10 kivezetéséig csak másfél év van hátra, a FreeBSD is a közeljövőben szünteti meg a 32 bites x86 támogatást. Az Apple ebben még előrébb jár, ők elsők között szüntették meg a 32 bites x86 támogatását, most meg az Mx platform miatt nemsokára már az x86-64-et is elavultatják az elsők között, ők sose törekedtek túl hosszú legacy supportra.

Ezt, amit most tolnak, már nekem is kezd sok lenni, pedig én mindig is szívesen adoptáltam az új technológiákat, próbálok haladni a korral, már akkor UEFI bootot, meg Waylandet használtam, mikor sokan azt se tudták a ma divatos soydevek közül, hogy azt eszik vagy isszák, vagy bottal sem merték piszkálni. Ez a mai verzióhajhász, meg erőltetett elavultatási ütem már nekem is veri ki a biztosítékot, és nem csak hogy ez jobb nem lesz, de egyre durvulni fog szerintem, elkapta őket a gépszíj, nem tudnak leállni. Így aki nagyon konzervatív, legacy/retró cuccokhoz ragaszkodó, nehezen vált, nehezen szok meg újat, nem akar kidobni régit, ami még működik, mint pl. hajbi, az mostanában nagyon kösse fel a gatyát, mert iszonyat kemény menet lesz.

Még azt se lehet mondani, hogy csak az Usákiában ilyen mániákusok a nagy multik, meg csak a Linux kockák erőlködnek ennyire a technológiai fejlesztésekkel, de EU-s és UK-es viszonylatan meg a 3G-t vezetik ki. Ha csak magyarhont nézzük, akár csak egy olyan kisebb magánközösséget is, mint az nCore, akkor ott meg idéntől az SD tartalmakat vezették ki, tiltották ki, ráadásul úgy, hogy az x265/x266 720p méretre kiváltotta volna, de azt csak 4K-ban engedik. Azon csodálkozok, hogy nemrég egyáltalán a magyar analóg rádió kegyelmet kapott, azt se tudni meddig.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

32 bites x86 procik mikor voltak utoljára? Rég kihalt a vas, ha megvan akkor sem akarsz olyat használni mai Linuxal, mert minek. Sok esetben a tesztelhetőség hiánya miatt is dobnak ki dolgokat, ha nincs gép amin tesztelni tudod akkor hülyeség bent tartani. A dead code mindig security risk.

Meg előbb-utóbb úgyis eltörik. Én egyszer csináltam olyat, hogy egy mikrokontrolleres környezet kétféle kommunikációs üzemmódot tudott, de többnyire csak az egyiket használtuk. Nagy teher volt, hogy minden új feature-be beletegyem a másik üzemmódot is. Az elején teszteltem, javítottam, utána csak beleírtam a hozzátartozó kódot, de nem teszteltem, egy idő után elengedtem, már bele sem írtam a kódot. Nagy teher volt, lélekölő duplán implementálni dolgokat, amiről tudod, az egyik ágat szinte sohasem használják. Aztán új hardware-t terveztem, abban csak egyféle kommunikációs metódus volt az adott feladatra, így ledobtam magamról végleg, lelkiismeret-furdalás nélkül ezt a terhet. :)

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

Nem ez a lényeg, nekem sem volt már sok éve 32 bit only procim, az utolsó értelmes gépet, amiben az volt, utoljára 2010-ben használtam (ami már akkor elavultnak számított, de azért használható volt még), meg volt egy átmeneti netbookos gépem 2016-ben, mikor ultramobilitás és anyagi megszorultság miatt kellett. A fő itt, hogy beindult mostanában mindenhol ez a féktelen, avultassunk el mindent hullám, aminek kezdem nem látni a végét.

Még az ext2 esete enyhébb is, mert itt még nem is szedik még ki, csak ellátják egy deprecated jelzővel, attól még évekig használható lesz talán, mindenesetre egy aggasztó tendencia része. A fele még eszembe se jut, pl. hogy pár éve pedzegetik, hogy sok régi Intel GPU-t is legacy csomagba tesznek át, kikerülnek az i915 driver alól. KI lett tiltva az SMB1, Network Discovery, NetBIOS, meg egy csomó mindent, és ezeknek jó része tényleg szutyok volt, de az összképet is nézni kell. A floppy drivert is próbálták már kinyírni. Annyi ilyet lehetne találni, ha összeszedném. Persze, mindig meg van indokolva, hogy régi technológia, dead code, secrisk, nem sokan használják, nem menő, kérdés, hogy ez az esetek hány százalékában jogos, és mekkora részben csak divat, fejlesztői kultúra, valóban elkerülhető, szükséges-e. Csak annyit mondok, hogy néha ezeket a szempontokat is át kéne gondolni, nem ész nélkül avultatni mindent, ami már nem tűnik menőnek, meg nem 4869-es verzió.

Mert érted, ma még csak az ext2, holnapra kitalálja, most a hasamra ütve, hogy a nálánál régebbi XFS, meg JFS is legacy kód, már az IBM sem veszi komolyan, meg IRIX hagyaték, rég nem volt commit, a karbantartó megunta a banánt, akkor mit csinálsz?

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Valóban el van avulva az az ext4, nagyon erősen. Lejárt a szavatossága, megpenészedett benne a non memory safe C kód. Használjon ZFS-t mindenki, azt is csak úgy, ha átírják a driverét Rust-ba, mert muszáj, RAM-ja meg úgyis van hozzá mindenkinek. A btrfs-t is dobjuk ki, jó pár éves, ott van helyette a bcachefs, az mindegy is, hogy még csak alfa állapotban, deadlockol, meg lassú, mint a szar, benchmarkokban a legutolsó helyen úgy kullog, hogy az előtte végző opció is többszörösen veri sebességben. A lényeg tényleg csak az, hogy a legújabbat kell hype-olni, mindenki torkán lenyomni, nincs ebben a soydeveknek (hajbazer ezeket babzsákfejlesztőnek hívja) választása.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A BTRFS bőven stabil manapság. Van helye az ext4-nek, de vannak csúnya gondjai is. Pl. nincs semmilyen checksumming. Nincs tömörítés. A klasszikus FSCK módszertana és működése egy borzalom, ne kelljen már megállítani a bootot és userspaceben szórakozni egy sima recoveryhez. Raid támogatás fájlrendszer szinten sem ártana.

Raid támogatás fájlrendszer szinten sem ártana.

Az nem rétegek fölötti átnyúlás? Szerintem a RAID filerendszer alatti réteg, mindegy, milyen formátumban mit írsz a szektorba, a RAID-nek semmi köze hozzá. Akár saját kitalációjú fs is lehet.

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

A zfs és a btrfs is tud ilyet, a lényeges része, hogy van checksum. Ha valahol eltörik akkor azt a lemezt berakja faultba. Ez azért elég hasznos tud lenni, a smart információ nem mindig tökéletes. Plusz lehet az eszköz jó, de pl. a kábele hibás, akkor nem fogja detektálni a vezérlő a hibát.

Nem is állítottam, hogy nem az. De egy vérbeli soydev bele tud abba is kötni, pl. hogy a ZFS feleslegessé tette, meg 17 éves fs, ráadásul nem safe C-ben írva, nincs Rust-ban újraimplementálva, nekik ennyi is elég kifogásnak.

Csúnya gondja mindennek van. Az ext4-nél nem volt fontos a chechsumming, akkora fokú redundancia, tömörítés, de ezek szoftveresen pótolhatók más rétegekben. Ilyen hátrányokat bármi ellen fel tudsz hozni, pl. ha a teljesítményt nézzük, abban az ext4 eléggé veri a többi megoldást. Kinek mi fontos. Nyilván akinek olyan nagy redundancia, tömörítés kell, annak nem kötelező az ext4-et, vagy xyfs-t használni, de aki meg használná, annak ne avultassák ki a kezei közül, ilyen-olyan álindokra hivatkozással.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A fájlrendszer maga kerekítési hiba a sebességben. Nyilván egy checksumming fájlrendszer valamivel lassabb, de bőven megéri. Az ECC ram is lassabb mint a sima, mégis el kellene felejteni a francba már a sima ramot. (256GB DRAM esetén kb. heti egy bithibát okoz a háttérsugárzás, ma már egy sima laptop tart 32GB-nél. Legalábbis nálunk a cégnél ennyivel rendelik.) Amikor majd beüt a szar akkor Linus megmondta 2 éve https://arstechnica.com/gadgets/2021/01/linus-torvalds-blames-intel-for…. Hasonló probléma amúgy flash memóriák és HDD esetén is fennáll csak ritkább.

Azért egy gyors keresést igazán megereszthettél volna, mielőtt hülyeségeket irogatsz.

A BTRFS bőven stabil manapság.

Annyira stabil, hogy már 7 éve deprecated.

Pl. nincs semmilyen checksumming.

De van.

Nincs tömörítés

De van, 2013 óta, csak a kutyának sem kellett, ezért nem mainline.

(A tömörítés egyébként is csak arra jó, hogy ne működjön a sparse és ne tudj pozícionálni nagy fájlokban (csak rohadt sok RAM és CPU erőforrás elpazarlásának árán), meg hogy feleslegesen belassítsd a fájlrendszert ha sok már eleve tömörített fájlod van. Majd azt én eldöntöm, hogy melyik fájlt akarom tömöríteni és melyiket nem!)

Raid támogatás fájlrendszer szinten sem ártana.

Szerinted. Tapasztalt üzemeltetők szerint meg sokkal jobb, ha független réteg, mert kevesebb a bug, függetlenül frissíthető stb. Az tök mindegy, hogy az FS modul vagy hogy a RAID modul jelzi-e a rendszergazdának, hogy winyót kell cserélni, kutyát sem érdekli, honnan jön a figyelmeztetés.

Csak Redhatban. SUSE és Synology esetén default. Plusz a facebooknál is használják elég rendesen commitok alapján.

Érted egyáltalán mi az a metadata? ZFS-ben és BTRFS-ben mindenre van checksum adatra is.

Az, hogy valaki beküldött valamit a kernel mailing listre nem jelent semmit. Az tuti, hogy ilyen feature nem 300 sor lesz, ha rendesen meg van csinálva.

Szerinted. Tapasztalt üzemeltetők szerint meg sokkal jobb, ha független réteg, mert kevesebb a bug, függetlenül frissíthető stb. Az tök mindegy, hogy az FS modul vagy hogy a RAID modul jelzi-e a rendszergazdának, hogy winyót kell cserélni, kutyát sem érdekli, honnan jön a figyelmeztetés.

Majd a fejlesztők eldöntik mit használnak, az üzemeltetés csak végrehajt. A HW raid mint olyan teljesen halott. 2024 van, egy új storage server az NVME SSD-vel lesz megpakolva. A PCIe meg közvetlenül a prociba megy, ott nincs satas HW raid, meg hasonló proprietary marhaságok.

"Szabadság, szerelem, ext2 kell nekem" - mondta a költő, de akkor még ő is fiatalabb volt.

Ha ezt most nem gúnyból írtad, akkor nagyon egyetértek. Ennek az Y2038-nak fel ne üljön senki, mert az ext2 driver épp úgy fordul 64 bitre is, meg lehetne rajta oldani a 64 bites időbélyegzőket. Írom ezt úgy, hogy nekem speciel ez az ext2 driver kivezetése tényleg nem fáj, mert amúgy sem használom már, nincs egy ext2-re formázott meghajtóm, partícióm sem évek óta, meg az ext4 driver is lekezeli, szóval alapból nem érdekelne, de ami nekem meredek, hogy ez is egy ilyen mondvacsinált kifogásokkal megindokolt elavultatási hullám része.

Mert oké, van helyette más, működik az is, meg lusták fenntartani a régit, akkor mondják azt, ne találják ki az Y2038-at, meg hogy ízé, nem memsafe, stb.. Vallják be, hogy ezen spórolnak most fejlesztői pénzt, időt, és akkor legalább nem beszéltek mellé. Azt is megértem, hogy ingyenes kód, a legtöbben, akik használjuk, nem fizetünk érte, ezért elvárás sem lehet, hogy valamit még x ideig, meg a végtelenségig támogassanak, csak kényelmetlen már a sok kifogás. Sőt, még azt is megértem, hogy a Linux kernel az egy dinamikusan növekvő valami, benne rengeteg legacy dolog, ha mindent benne hagynának a végtelenségig, csak nőne-nőne a mérete, és a végén kezelhetetlen lenne az egész, így kénytelenek belőle időnként ezt-azt kimetszegetni, elengedni, szanálni.

Ma még csak az ext2 driver megy a levesbe, de holnap mit találnak ki? Lassan már nem csak a soydevek avultatnak el, már őket is elavultatja az AI, majd az ír meg minden kódot, az lesz csak a jó világ, akkor már őket is visszasírjuk, meg a Rust-ot.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az lehet, hogy lefordul 64 bitre, csak kérdés, a metaadat formátumban hova teszed a felső 32 bitet. Számolhatsz te akármilyen felbontással, ha a filerendszerben ott van, hogy mondjuk 8, 9, 10, 11. byte pozíció a timestamp. És akkor hogyan tovább? Ez persze akkor is igaz, ha ext4 driver piszkálja az ext2-t. Gondolom, az a megfejtés, hogy újabban formázott ext2-nek más a metaadat formátuma, s gondolom, van a filerendszernek verziószáma is épp ezért.

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