A ReiserFS-t végül eltávolították a Linux kernelből

Fájlrendszer, NAS, storage

Részletek itt.

( goodbyte v | 2024. 11. 24., v – 11:30 )

Kár érte, jó katona volt (soha se használtam).

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

( dejo v | 2024. 11. 24., v – 14:55 )

Szerkesztve: 2024. 11. 24., v – 14:56

Én sem használtam soha, de tudott valamit amit a zfs vagy a btrfs nem és nem lehet meglenni nélküle?

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Nekem érdekes hibám volt reiserfs-en, többször is előjött. Valami rejtélyes okból - ha jól rémlik - időnként a /var/log/Xorg.0.log file vált read-onlyvá, és mellesleg emiatt az X indítása elhasalt. Visszaállítva read-write-tá minden OK volt, aztán egy idő után ugyanaz a hiba előjött ismét ugyanezen. Lehet, hogy nem csak itt kavart be valamit a reiserfs, de mást nem vettem észre. Miután dobtam a reiserfs-t (xfs-t használtam utána), ezek a problémák megszűntek.

Az ezredfordulón már módosított Debian install disk-et csináltam a tesómmal reiserfs support-tal (ezt hívják magyarítva korai örökbefogadónak?) - akkor még nem volt más naplózó fájlrendszer és áramszünettel szemben nem volt olyan ellenálló az ext2. Reiseren nekem sem volt adatvesztésem.

Btrfs-sel viszont nekem is volt többször is porblémám. Pedig nem történt semmilyen gimnasztika (nem voltak egzotikus subvolume-ok, vagy ilyesmi), csak sima deployment. A második ilyen óta nem használok btrfs-t, tesztelje helyettem valaki más.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Igen, JFS és XFS előbb létezett, bár elég relatív. Mert pl. a JFS már a Linux előtt létezett, de az a 32 bites JFS1 volt, amit meg ma használnak, az a 64 bites JFS2, ami továbbra is JFS-nek van csak aposztrofálva, az 1999-ben jelent meg. Az XFS ugyan a Linux után jelent meg, de még az echte linuxos fájlrendszerek (ext, reiser, stb.) előtt IRIX-en, de a Linux kernelbe csak 1999 után került be, mert akkor lett GPL licencű. Aztán akkor döntse el mindenki, hogy melyik volt előbb, a csirke vagy a tojás.

Egyébként a JFS csak az AIX-szel való kompatibilitás miatt van a kernelben, és arról is rebesgetik, hogy ki kéne szedni, mert régóta nem nagyon tartja karban senki. Ahogy írtam már múltkor, az az egy fs, amit még én se próbáltam ki soha, nem azért, mert bajom lenne vele, csak sose vitt rá kíváncsiság.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Itteni kolléga is Maildir formátumú levelezést ReiserFS-re pakolt fel nálunk. Adatvesztést fájlrendszer miatt nem tapasztaltunk, pedig rohadt már ki merevlemez, alaplap meg tápegység alóla. Több volt a küzdelem a különféle Outlook verziók IMAP implementációival :(.

Igen, 2001-ben már elérhető volt, a korai 2.4.x kernel verziókban.  Pár hónappal később jött ki az ext3 is, úgyhogy annak volt a direkt alternatívája.  Akkoriban előnyös volt a "sok file egykönvtárban" scenario esetén, mivel B+ tree-ben tárolta a könyvtárszerkezetet, valamint a sok kis file esetén is (tail packaging feature).  Emiatt raktuk például NNTP server alá, ha még emlékszik valaki a Usenet-re :D  Előbbire az ext3 évekkel később hozott alternatívát (dir_index feature).  Egy időben a SuSE (akkor még német distrib volt és így írták) default filerendszere volt.  Mi workload-tól függően később ext4-re vagy xfs-re migráltunk róla.

Talan a 3.6-os verzio volt a kernelben, ami osregi. Kozel ket evtizedig letezett a 4-es is kulso patch formajaban (ami a karbantartonak eleg massziv problema volt, mert minden a kodjat erinto kernel modositast sajat maga kellett, hogy atvezessen). Mostanra mar nem sok ertelme maradt a 3-as hasznalatanak, az uj filterendszerek, foleg a btrfs (Chris Mason annak idejen a ReiserFS-en is dolgozott, lehet, hogy onnan meritett otleteket) kivaltjak minden elonyos funkciojat, cserebe egy rakas ujabb dolgot tudnak (titkositas, snapshotok, ...).

Amúgy azon túl, hogy divat a mindentegyben FS, mennyire éri meg, mint külön a LUKS, md meg az LVM, amik már, gondolom, elég érett technikák?

Synology-nál is, ahogy olvastam a BTRFS-ből se használják pl a RAID funkciókat. Én mondjuk annak is örülök, hogy legalább a fájltömörítés bekapcsolható, kár, hogy a deduplikáció nem, csak a saját NVMe meghajtóival, ha jól olvastam.

NetHServer-t próbáltam annak idején BTRFS+tömörítés+deduplikáció mellett teszt e-mail szervernek (RAID nem volt, VM-en futott, a vason meg volt RAID). Sajnos egyszer összeomlott és a BTRFS partíció odalaett, utána már csak a gyári alaprendszert használtam, azon stabil volt.

A filerendszer szintjen implementalas vs block device (valamelyik layerben) azert sok szempontbol elonyos, bar nyilvan koveli a komplexitast igy hibalehetoseget is hoz be. Titkositani lehet egyes fileokat, nem a teljes device-ot, snapshotolni is lehet csak egy fs (sub)volume-ot, nem a komplett device-ot es konzisztens is, nem marad kiiratlan adat valahol pufferelve. A checksum is igencsak hasznos (nem kell idonkent vegigolvasni a teljes mdraid device-ot, hogy eltereseket talaljunk), hogy az adatkorrupcio kideruljon, es javithato legyen, ha rendelkezesre all masolat.

Szerintem nincs egyertelmuen mindent a legjobban tudo filerendszer, ami minden mast elavultta tesz. Se a zfs, se a btrfs, se a bcachefs, ... En a mai napig xfs-eket hasznalok a regen felhuzott gepeimen, fejlesztik ugyan az xfs funkcionalitasat, de tobb szempontbol elavultnak szamit a modern filerendszerekhez kepest.

Amúgy azon túl, hogy divat a mindentegyben FS, mennyire éri meg, mint külön a LUKS, md meg az LVM, amik már, gondolom, elég érett technikák?

Semennyire. A független rétegek mindig is karbantarthatóbbak és megbízhatóbbak voltak / lesznek. Mindig.

A fájl titkosítás egyértelműen biztonságosabb, mint a block device titkosítás. Utóbbi esetben a fájlrendszer struktúrák ismertek

Bolond vagy és félrebeszélsz. Pont fordítva van, block device titkosítás esetén NEM ismertek a fájlrendszer struktúrák és bármilyen fájlrendszerrel is működik.

pedig ebben neki van igaza, es pont neked kene tudnod ezt aki irt mar tobbfele filerendszerhez parsert, hogy minden fs-nel vannak olyan szektorok, ahol lehet tudni mi van ott. pl fs headerek, ures mft/inode tablak, stb.

anno a dvd vedelmet is azzal tortek fel (DeCSS), hogy ismertek volt az mpeg2 fejlecek, igy lehetett tudni bizonyos szektorokban mi kell legyen.

ugyebar barmilyen titkositas feltoresenek elofeltetele hogy legyen olyan input+output mintad amit azzal a kulccsal kodoltak le. inputod (titkositott adat) nyilvan van vegtelen, de van-e annak megfeleltetheto dekodolt minta, legalabb egy par 100 byte?

persze ez fileok eseten is adott lehet, vannak olyan fileformatumok ahol akar az elso 200 byte is fix, pl a regi word/excel .doc/.xls ilyen az OLE2 headerek miatt (ami mindig ugyanaz: GUID, verzioszamok, sok 00), vagy pl. az mpeg2, es talan egyes jpeg variansok is (EXIF headerek pl).  de filerendszerek eseten altalaban konnyebb egybefuggo nagyobb blokkokat talalni aminek lehet tudni a dekodolt tartalmat a kulcs nelkul is, csupan a filerendszer tipusa es merete alapjan.

persze ha eleg izmos a titkositas (pl. aes256+) akkor hiaba van meg input+output mintad akkor is vegtelen sok eroforras a kulcs megtalalasa, igy mar lenyegtelen az egesz. viszont minel erosebb a titkolozas annal lassabb lesz az i/o, ami pl 4-8 gb/s nvme ssd eseten mar erezheto, de egy regi sata vinyonal a mai cpu-kkal kb mind1.

( arpi_esp v | 2024. 11. 24., v – 19:51 )

Szerkesztve: 2024. 11. 24., v – 19:51

RIP. kar erte, mai napig hasznalom production kornyezetben... jo moka lesz atmigralni, bar 13-as szamu kernelt ugyse raknek fel sehova, foleg penteken :)

Erre számítani lehetett. Már egy éve beszélték a kernelfejlesztők, hogy el akarják távolítani, kb. fél éve deprecated státuszt kapott, így nem kell csodálkozni, hogy ténylegesen is kiveszik. Bőven volt időd migrálni. Különben nem kell mindent migrálni, csak ha / partíciód van rajta, amiről rendszer fut. Adatok alá gondolom továbbra is fognak szállítani userspace drivert, amivel eléred a ReiserFS-en lévő cuccaid, csak legfeljebb szarabb teljesítménnyel.

Sose használtam, de kár érte. Ha a projekt indítójának nem lett volna ilyen rossz neve, nem gyilkolja le a feleségét, akkor ki tudja hová fejlődött volna mára ez a fájlrendszer, ha aktívan karban is tartják. Így viszont ment a süllyesztőbe.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> Bőven volt időd migrálni

hejj, raerunk arra meg ;)  hatha kikopik/kidoglik alola a vas addig, gondolta moricka.

amugy meg max 6.6 kernelt hasznalok de inkabb 5.15 azokkal meg megy egy darabig, mire a next LTS kijon reiser nelkul mar talan en is nyugdijba megyek.

mindenesetre mar ugy 3-4 eve az uj rendszreeket btrfs-el epitem

Ja, lustaság, tudom én. Most néztem meg, már 2+ éve be volt harangozva, hogy dobni fogják. Azóta deprecated, most kiveszik. Egy gáz van benne, nem biztosítanak helyette fuse vagy hasonló userspace megoldást, ez valóban nagy hanyagság, azzal rövidre zárják, hogy használj hozzá régi kernelt. Legalább egy KMS kernelmodult vagy hasonlót tarthatna valaki karban hozzá, tényleg csak arra az esetre, ha valaki beröffent egy ilyen régi ReiserFS alapú rendszert, vagy partíciót, legalább az adatait ki tudja menteni a szerencsétlenje, ne kelljen neki régi, elavult kernellel, vagy virtuális géppel vergődnie.

Mondom, én egyébként sajnálom, mert 33 ezer programsor, ezen negyed évszázadot dolgozott több ember, most a munka megy pocsékba, ki lesz öntve, pedig lehet lehetne rajta még fejleszteni, optimalizálni, hogy a belefektetett embermunka megtérüljön. Ezt sok régi szoftvernél megfigyeltem már az évtizedek során, hogy annak idején beleöltek a fejlesztésbe rengeteg pénzt, emberórát, aztán kiavul alóla a platform, több nem futtatható, csak emulátorban, meg eredeti retró vason, és így pocsékba meg a beleölt erőforrás, nem hasznosul egy ponton túl, ez pazarlás szerintem. Értem, hogy a fő fejlesztő, akinek a nevét viseli, az megölte a feleségét, de egy nem szakmai, személyes vonatkozás, amiért évtizedek óta bűnhődik is, az általa fejlesztett megoldást szakmailag nem ennek alapján kéne megítélni, de hát ez van, a sok polkorrektkedő ezt nem tudja megemészteni, bojkottálták emiatt a projektet, elhalt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> Ja, lustaság, tudom én. Most néztem meg, már 2+ éve be volt harangozva, hogy dobni fogják

tudom, es biztam benne hogy ennyi ido alatt ugyis lecserellik a gepeket is. ez van ahol megtortent van ahol nem, de mivel a 6.6 lts kernelben meg benne van es az lesz meg legalabb 2 evig annyira nem kell izgulni :)

en mar kb 3 eve uj telepiteseknel btrfs-t hasznalok, elotte is probalgattam de sok gond volt vele. mondjuk meg mindig van, epp tegnap szivtam egy raid kartya fagyas miatt megzakkant btrfs megmentesevel.

de tenyleg kar erte, 20 eve megbizhatoan mukodo fs-t kidobnak, es nem is nagyon van alternativa, csak a kisse bugos btrfs, a 3rd party zfs, a vicc kategoria bcachefs es tarsai...

esetleg ext4, bar pont a nyaron jartam ugy, hogy egy pendriverol friss linuxot bootolva formaztam ext4-re egy disket aztan egy korabbi rendszert mentesbol ramasolva az nem indult el rola mert valami nem tamogatott ext4 feature is be volt kapcsolodva. tok jo, hogy az mkfs.ext4 minden bleeding-edge featuret bekapcsol by default, azt is amit az 1 evvel korabbi kernel nem is ismert.

( lacesz v | 2024. 11. 24., v – 21:28 )

Kár érte.. Mai napig minden rendszeremen azt használom. Hans azt mondta, ha kijön újraírja az egészet. Remélhetőleg kiengedik az elkövetkezendő időszakban. Kár volt Reisernek azt tenni amit tett. :(

Offtopik, de számomra azért ez egy elég nagy rejtély, hogy lesittelnek mondjuk egy szoftverfejlesztőt (orvost, akármit), és kiviszik kukoricát címerezni, vagy rosszabb esetben hagyják megrohadni a cellában, az adófizetők meg fizetik a számlát. Szerintem simán* lehetne, hogy érdemi munkát** végezzenek, amiből kapnak valamennyit a saját BV számlájukra, a többi meg mehet a közösbe. Járulékos előny, hogy a fogvatartott sem fog bekattanni a semmittevéstől --> nagyobb eséllyel tud visszailleszkedni a társadalomba.

* Még úgy is, hogy az állam dotálja az ilyen munkahelyeket, bőven-bőven megérné
** Értsd jól, ahol a körülmények megengedik. Mondjuk egy adócsaló orvos simán elláthatna egy háziorvosi körzetet (akár remote), ahol most nincs senki. Nyilván akit azért ültettek le, mert megölte a betegeit, az nem.

ez mondjuk tényleg egy támogatandó ötlet

szerk: közben beszélgettem a témában jogász ( ügyvéd és bíró is volt ) hozzátartozóval, de sajnos több kérdést vetne fel mint amit megoldana jogi szemmel nézve.

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

Tudom, de mi itt az ellentmondás?

Tegyük fel hogy van egy szakorvos, akit leültetnek hálapénz miatt. Btk. 290. § (6) -> vétség -> első alkalmas -> fogházba kerül fél évre. Mi van akkor, ha nem a fogházban látna el könyvtárosi munkát, és nem a könyves kocsit tologatná a többi sittesnek, hanem mondjuk az állami eü keretein belül foglalkozna olyan betegekkel, akik mondjuk alapesetben nem jutnak hozzá az adott szakellátáshoz, mert pl. nincs az adott területen megfelelő képesítésű orvos?

Mit nyerne/veszítene egy ilyen rendszerben

  1. a fogvatartott,
  2. az államkassza és
  3. a betegek?

Nem az volt a felvetésem, hogy mindenki szabadon élhessen a hobbijának, miközben fogházban/börtönben van, hanem hogy (ahol a körülmények engedik!) ne csak az adóforintokat égessük, hanem legyen valami kompenzáció.

Sőt, továbbmegyek, be lehetne vezetni olyan rendszert (fárasztóak ezek a disclaimerek, de itt megint csak értsd jól: nem a hivatásos börtöntöltelékre gondolok, hanem alapvetően normális állampolgárokra, akik hibáztak valahol), hogy amikor az ítélet megszületik, ott eleve úgy lehetne meghatározni a szabveszt mértékét, hogy X idő, amiből lesz a végére mondjuk 0,75*X, ha konstruktív dolgot csinálsz közben, vagy 1,5*X, ha csak számolod a napokat a cellában.

Nyilván ez egy gondolatkísérlet, az implementációs részletekbe biztos ezer helyen bele lehetne kötni. :) A lényeg akkor is az, hogy a képzett, potenciálisan jól reintegrálható elítéltek ne egész nap a brét verjék a sitten, hanem csináljanak valami olyat, ami kompenzálja a rájuk eső állami kiadásokat, és segítse a társadalmi reintegrációt.

YMMV, de nekem bőven elég elrettentő erő az, hogy bezárnak valahova, ahonnan csak dolgozni mehetek el, egy olyan helyre, amit az állam jelöl ki, és ahonnan a fizetésem (hasamra ütök, és) 80%-át lenyúlják az "ingyenes" lakhatásom fedezetéül.

A börtönnek kurvára nem attól van elrettentő ereje (számomra), hogy nyomorultak a körülmények, mert felőlem bezárhatnak egy wellness-szállóba is, attól még ugyanúgy kimarad X év az életemből, közben felnőnek a gyerekek, kimaradok a családom életéből, nem csinálhatom a hobbijaimat, nem találkozom a barátaimmal, stb.

ha az akarat megvolna hogy szabályozzák valószínű meg lehetne oldani, de mint lentebb is irtam, se politikus se jogász nem vagyok, szóval az öteletet jónak tartom, de eldönteni nem tudom hogy megvalósítható -e.

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

Amikor feldobok egy ilyen ötletet, abban implicit benne van, hogy ez nem egy alulról szerveződő dolog, hanem jogalkotói szándék is van mögötte :)

A kérdést egyébként úgy kell feltenni, hogy Kovácsné, maguknál a faluban nincs háziorvos 10 éve. Most vagy elsétál a legközelebbi városba (mert már tömegközlekedés sincs), vagy itt van ez a doki, jó szakember, csak hát sittes, mert adót csalt a háziorvosi praxisában. Nyilván nem kötelező a dokit választani, lehet sétálni is. Sőt, a dokinak sem kötelező ebbe belemennie, ülhet a cellában is, csak ott lassabban telik az idő.

Nem-nem, teljesen jó a példád! Pont ezért lennék kíváncsi konkrét számokra. Mert mióta kovid közepén bevezették a hálapénz kommandózást, mennek a híradások non-stop h. minden héten telibusszal viszik a lebukott osztályvezető főorvosokat Nógrád, Borsod, Szabolcs megyéből a kóterba.

foghazban is csomo olyan szabaly van amit igy konnyen ki lehet jatszani: nem veletlen hogy csak konyvtarosi munkat/kapalast adnak ilyenkor. onnan nincs mit becsempeszni a cellaba.

gyanitom ez az otlet megfordult mar masok fejeben is, csak amikor feljott hogy "meg kene csinalni biztonsagosra", akkor kijott hogy dragabb mint amit hoz+a mostani allapot.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

most eltekintve attól hogy a vészhelyzeti kormányzással egyetértek-e nem vagyok se jogász , se politikus. az ötletet, hogy az elitéltek visszadolgozzanak a társadalomba jónak tartom. hogy megvalósítható-e azt nem tudom eldönteni.

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

goto

tl;dr a családot nem látod, este seggbekúrnak a zuhanyban, szar a kaja, egy zárkában vagytok hatan és középen van a budi, a fizetésed 80%-át leadod állambácsinak, stb. Szerintem elég büntetés ez, már nem sok vizet zavar, hogy könyvtáros leszek-e a dutyiban, vagy szoftverfejlesztő

Jah, lehet.

Meg gondolom betanított munkásnak vinni egyszerűbb, mint azon gondolkodni, hogy hova lehet elhelyezni RKE ops munkakörbe valakit a sittről. Meg ugye menne az állásinterjú, hogy oké, végülis nem baj, ha sittes, csak a fullstack dev pozihoy kevés a frontend tudása :)

Hát... kapálást, kefe- seprűkötést vagy fazekasságot viszonylag egyszerű felügyelni és ellenőrizni (kb a smasszer elég hozzá), na de egy orvos vagy informatikus munkáját? Elítélttel kapcsolatban azért van egy nagy bizalomhiány szerintem - amire persze hathat a bűntett jellege is, de azért na. Nem tudom hogy tud kifizetődő lenni.

Ha minden igaz, a szakmunkák 90%-át ma is belsőleg oldja meg a BV, börtön felújításokat stb. Nem feltétlen kellene egy orvosnak vagy it-snak se külső munkán dolgozni, hanem belsőleg lehetne. Gondolom a bv-s orvos meg IT-s is hasonlóan alulfizetett mint a sima börtönőröké.

De pl. it siman csak L1 supportot is biztosíthatnak az államigazgatás számára, stb. user értékeléssel. Ott bent hidd el, nem törekszik senki sem arra, hogy elszarja a munkáját, és nem dolgozó körletbe kerüljön, esetleg még más kedvezményt is megvonjanak.

Domain, tárhely és webes megoldások: aWh

Valakinek kell felelősséget vállalni az ilyen melókért. Én nem igazán tudom egy kalap alá venni egy kőműves vagy asztalos munka felelősségét egy (belső) IT rendszerhez való odaeresztéssel - ahol belső információkat, dokumentumokat ismerhet meg potenciálisan vagy kicsit bonyolultabb megállapítani a károkozás felelőseit. Tintapatront persze lehet cserélni meg kábelt húzkodni de Gizikének excelben segíteni már nem biztos hogy ajánlatos.

Az IT munkaerőnek szerintem amúgy sincs ilyen "rabmelóztatás" feladat a munkaköri leírásában (a háta közepére se hiányzik és nem is alkalmas rá).

Nem feltétlen a szoftveres részét kell intéznie. Húzhatnak kábelt, utp-t szerelhetnek, gépet takaríthatnak, stb.

Nem tudom mire gondolsz rablemóztatás alatt itt most. A kiinduló pont az, hogy mindenki dolgozzon a börtönbe (ez a bv álláspontja is), de hatákonyabb lenne a szakképzett embereket arra használni, amihez értenek. Mert persze az orvost is elküldhetjük segédmunkára, dolgozik is, csak nem biztos, hogy az az optimális.

És itt most ugye arról van szó, amikor nem a szakmájában lévő dolgot követett el, pl. ittasan balesetet okozott vagy ilyesmi, annak nincs köze a melójához, miért ne dolgozhatna abba ugye. Eleve van olyan intézmény ahol rendesen elengedik a fogvatartottakat dolgozni, normális munkahelyre. Szóval itt csak az akarat hiányzik, ahhoz, hogy mi legyen. (és ha mondjuk it, a szoftveres ember, ok, BV dolgokhoz nem engedjük, de a bv intézményekben attól még ugyanúgy van egy rakat számítógép, könyvtárba, oktatáshoz, stb. azt is karba kell tartania valakinek).

A kőműves meg asztalos melóját se lehet szemrevételezéssel megállapítani, ok, a fal ott van, de az a segédmunkás szintje, nem a kőműves, ha nem ért hozzá az őr, úgy át lehet baszni, mint ahogy a való életben is átbasszák az embert. a komolyabb szakmunkákról nem is beszélve, villanyszerelés, fűtésszerelés, stb. és ezek is meg vannak oldva az ellenőrzése.

Domain, tárhely és webes megoldások: aWh

( dyra | 2024. 11. 25., h – 11:18 )

Szerkesztve: 2024. 11. 25., h – 11:18

Kár érte. Korábban csak ezt használtam, főleg azért, mert gyors volt. Ez igazából a merevlemez érában volt jó.

Igen, konkrétan ez lett a fájlrendszerek fejlesztésének a veszte. Megjelentek az egyre gyorsabb SSD-k (és csatolófelületek, protokollok), ahol teljesítményben nem annyira számít, hogy milyen gyors egy fájlrendszer, mert maga a drive van olyan gyors, hogy elfedi a szoftveres lassúságot, és máshol lesz úgyis a bottleneck. Az is segít, hogy a mai gépekben bőven van sok giga memória, így sok minden jobban cache-elhető is. A másik oldalról, meg a feature heavy fájlrendszerekben (ZFS, Btrfs) implementáltak minden elképzelhetőt, így már ezeken sincs mit fejleszteni, nincs már új a nap alatt, nem lehet forradalmasítani, csak a kereket lehetne újra feltalálni. Limitációk is ki vannak tolva, mióta 64 meg 128 bites fájlrendszerek vannak, olyan távoli lett a fájlrendszerbeli, fájlméretbeli, stb. limit, hogy sose érjük el, exabájtok. Kisebb bugjavítások és optimalizációk jelennek meg a meglévő fájlrendszerekhez, és kb. ennyi. Az utóbbi években csak a f2fs volt új, de az se váltotta be a hozzá fűzött reményeket, meg a bcachefs, amivel szenved a fejlesztő, nem halad sehova, bugos, lassú, nem tudja a létjogosultságát bizonyítani a Btrfs ellenében. A MS se gurított nagyot az ReFS-sel, lényegében egy kicsit bővített funkcionitású NTFS, csak át van nevezve, meg prémiumnak eladva.

Ezek a fájlrendszerbeli kérdések valóban a merevlemezeknél voltak fontosak, főleg a régieknél, ahol az adatsűrűség nem volt nagy, és nem volt még bennük cache vagy nem sok, azok pokoli lassúak voltak, így minden csepp teljesítményt ki kellett sajtolni belőlük, ha kell defraggal, ha kell swap partícióval (azért nem fájllal, hogy ne töredezzen, és még arra is figyelni, hogy a swap partíció a tányér külső szélére kerüljön, ahol gyorsabb az adatelérés), stb.. Akkoriban a kevés memóriás gépekben (ezen azt a korszakot kell érteni, mikor megabájtokban mértük a RAM-ot, nem gigabájtokban) a cache-lés se lehetett megfelelő mértékű. Játékoknál is vadul optimalizáltak, hogy az adatok szekvenciálisan legyenek beolvasva. Ma már az ilyen bűvészkedésekre nincs szükség.

Épp ezért nem hiányzik senkinek a ReiserFS, nem szólna mellett érv akkor se, ha nem vennék ki. Ha ki is engednék Reisert a börtönből, amire kicsi az esély, de tegyük fel, hogy a nem túl távoli jövőben megtörténne, akkor se nagyon tudna a mai felállás mellett túl sokat összehozni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Offtopik: volt anno egy Exchange -> EXO migrációs projektünk, ahol az ügyfélnél 1 kivételével az összes mailbox gond nélkül felment a felhőbe. A maradék egyet nem értettük. Kiderült, azért nem, mert Exchange Online-ban max 250 (?) folder lehet egymásba ágyazva. Nem annyi karakter hosszú lehet, hanem annyi nested subfoldert enged. Azaz: ./Ez 1 folder/Ez még egy folder/.../Ez 200 folder/*

A srác túllépte a limitet. Máig nem tudom, hogyan.

( oykawa | 2024. 11. 25., h – 13:22 )

Szerkesztve: 2024. 11. 25., h – 13:23

Sub

Oykawa