Hans Reiser ismét kérte a Reiser4 beolvasztását a mainline Linux kernelbe

nem rossz gondolat :) azt hiszem itt az ideje annak, hogy a BSD-s sourceokat is alaposabban áttanulmányozzam. mivel nem vagyok profi (értsd: szakmabeli/fizetett) programozó, tényleg nem tudom mennyire megoldható a cpp makrók és a typedefek nélküli programozás, de számomra tény, hogy az olvashatóságon erősen rontanak az efajta kódolási manőverek.


egyébként amikor a minap újra áttekintettem néhány sor - linux - kódot, feltűnt a statikus "string"-ek (ugye C-ben nincs olyan, hogy "string") használata olyan helyeken is, ahol egyébként teljesen felesleges lenne. a benyomásom mindig is az volt, hogy ilyesmit csak olyanok tesznek akiket vagy a) nem érdekel a kód sebessége és/vagy memóriahasználata b) olyan programnyelvben jártasak amelyben ez megszokott (pl dinamikus nyelvek, pl perl, php stb). ezekután persze már nem tudom mit gondoljak, lehet, hogy csak én vagyok ennyire fanatikusan tökéj-mániás és a valóságban _ennyire_ nem számottevő az a sebességbeli veszteség amelyet a statikus stringek használata eredményez.


ha valaki netán nagyon ott lenne ebben a témában, hálás lennék ha megosztaná velem hogy akkor ez hogyan is van :)

A kod sebessege es alacsony memoriafelhasnalasa altalaban egymasnak
ellentmondo kovetelmenyek. Ez nagyjabol azt jelenti, hogy egy kodot vagy
sebessegre, vagy memoriafelhasznalasra optimalizal(hat)ok. Nem azt jelenti,
persze, hogy a ket kovetelmeny kizarja egymast, de altalaban egymas
rovasara lehet oket javitani.

Tipikus alappelda:
adataok minden felhasznalaskor valo kiszamitasa/keresese/feldolgozasa stb.
vs. egyszer kiszamolasa es eltarolasa

A konkret esetben a kerdes az, hogy az adott valtozo mennyi ideig el, azaz
mennyi ideig foglalaja a memoriat. Ha tehat en statikus stringet hasznalok
de a valtozom elettartamat a leheto legrovidebbre veszem, akkor mit is
nyernek ebben az esetben a dinamikus helyfoglalassal? Hat max. annyit, hogy
C-ben a string tenyleges hosszanak megfelelo valtozot csak a dinamikus
helyfoglalasnal tudok letrehozni. Tehat ennyit. Azt, hogy nehany ms ideig
nem a tenyleges hosszat, hanem egy felulbecsult hosszat foglalok. Puff
neki. Lehet olyan eszkoz, ahol ez szamit, ott oda kell ra figyelni,
kulonben meg lenyegesen dragabb a programozo ideje (na meg a hibakereses, a
kod bonyolultsag, stb, stb), mint a nagyobb hardware. (Egybekent a C string
kezelese meg ugy ahogy van szar, es mint tudjuk ez utobbibol nehez varat
epiteni.)

A fenti peldaban a statikus es dinamikus helyfoglalas a vegrehajtasahoz
szukseges idokulonbseget (ha van), tekinthetjuk forditofuggonek, es jo
esellyel elhanyagolhatonak.


> egyébként amikor a minap újra áttekintettem néhány sor - linux - kódot,
> feltűnt a statikus "string"-ek (ugye C-ben nincs olyan, hogy "string")
> használata olyan helyeken is, ahol egyébként teljesen felesleges lenne. a
> benyomásom mindig is az volt, hogy ilyesmit csak olyanok tesznek akiket
> vagy a) nem érdekel a kód sebessége és/vagy memóriahasználata b) olyan
> programnyelvben jártasak amelyben ez megszokott (pl dinamikus nyelvek, pl
> perl, php stb). ezekután persze már nem tudom mit gondoljak, lehet, hogy
> csak én vagyok ennyire fanatikusan tökéj-mániás és a valóságban _ennyire_
> nem számottevő az a sebességbeli veszteség amelyet a statikus stringek
> használata eredményez.

en aztan tavolrol sem vagyok egy reiser-felhasznalo/-hivo, de ez nagyon tetszett:

Horst von Brand: "You should thank him [..Christoph Hellwig..] for doing the (hard, boring, thankless) work of reviewing code for free. Even if it isn't yours.

As he is doing it as community service, I wouldn't dare blame him for picking whatever he likes most, for whatever reasons."

Hans Reiser: "Well maybe he should just go away then and save his and our time.

Reiser4 works just fine without Christoph.

Users are happy with it. None of them have asked for his help."

:)

A ReiserFS a default fájlrendszer a SuSE, Lindows, FTOSX, Libranet, Gentoo, Xandros és Yoper disztróknál. Tehát nem lehet annyira rossz.

Nem értem, miért akarják mellőzni Mortonék. Az, hogy eltér stílusa a kernel többi részétől, elég átlátszó kifogásnak tűnik.

de hat nem erted?! ok szabadidejukben nezik at a kodot -> tehat -> jobban tudjak mi jo neked. ugyhogy ezert mostantol eleted vegeig koszonettel tartozol.

Nekem semmi közöm a témához (azon kívül, hogy használója vagyok) de, ha erről van szó, tényleg értelmezhetetlen kifogás a "kód stílusa".

Egyrészt véleményezés kérdése, másrészt ez pont az a dolog amit talán a legnehezebb megváltozatni. Tehát ha szálkát kell keresni, akkor ugye ideális. Valószínübb, hogy személyeskedések vannak a dolog mögött.

Reméljük hamar felülemelkednek a dolgon és találnak valami kompromisszumot, hiszen ez egy nagyszerű stuff!

Vegyük észre, h nem csak a coding style a gond, az csak (szerintem mesterségesen) lett felfújva. Lásd Christoph legelső levelében a felsorolást.

szerintem itt egy kicsit máshol vannak a hangsúlyok.

a fő gond nem a stílus, hanem az hogy csomó dolog

- még mindig bugos, vagy legalábbis gyanús

- a szerzők saját szája ízük szerint próbálnak meg megvalósítani, és nem a kernelben megszokott módon. pl újraimplementálnak több függvényt, ami így a beolvasztással kód duplikálódást okoz. Vagy feleslegesen túlbonyolított kódot tesznek bele, ami aztán karbantartási túlmunkát okoz, stb stb

szóval nem arról van szó, hogy valaki hova teszi a kapcsos zárójelet, hanem arról hogy nagy szoftverrendszert konzekvensen kell fejleszteni, mert egy idő után nem lehet majd karbantartani.

végül is reiser akar kódot a kernelbe juttatni és nem fordítva. alkalmazkodnia kell, ami jó kódolók szupernagyra fejlődött egójával nem mindig könnyű.

így kapisgálom már miről van szó :)

kösz

Az a Reiser 3.

Ez egy újabb, másik verzió, és a kernelfejlesztők problémája a thread szerint, hogy... Khm, hogy is fejezzem ki szépen: egy összetaknyolt *****.

A reiser4 nem a reiser3 kódra épül? Újraírták az egészet?

Akkor meg is érdemlik...

Amugy szerintem nagyon is igaza van Reisernek amit a filerendszerekrol mond. Az _mas_ kerdes hogy a reiser4 ilyen vagy olyan (gyakorlati tapasztalat hianyaban nem tudom), de attol elviekben szerintem meg igaza van hogy az egesz VFS model is ami a UNIX-okat alatalaban jellemzi az mar kezd finoman szolva is idejetmulta valni ... Nezzuk csak az atala emlitett peldat is: van akar egy tobb Gbyte hosszu file-unk, ha egyetlen byte-ot be akarunk "kitorolni" a file elejerol: ujra kell irni az egesz filet. Egyetlen byte miatt ... Pedig ugyanugy ahogy van truncate, elvileg erre is lehetne megfelelo hivas ... Az LKML-t olvasva nekem ez jott le, hogy a kernel fejlesztok tobbesege viszont nem csak a reiser4-et utasitja el, hanem magat az elevet is, hogy barmi komolyabbahoz hozza lehet nyulni, legyen szo itt a reiser4-rol vagy barmi mas kapcsan errol. En csak azt akartam ezzel leirni hogy ez (is) elgondolkoztato. Viszont az is igaz hogy a reiser4 kapcsan a flamewar ami az LKML-en is volt nem ritkan igencsak szemelyes hangnembe csapott at, aminek mar nincs sok koze semmifele technikai ervhez ...

Persze, a megfelelo hivas meg ujrairna az egesz file-t egy byte miatt... Minden bizonnyal szukseg van ilyen rendszerhivasra, szinte elni sem tudunk nelkule...

A szemelyeskedesrol meg annyit, hogy ha pl. mar evek ota fejlesztesz valamit, csiszolgatod fenyezed, mukodik, stb... es hirtelen feltunik egy Reiser fele meretes arcu ficko, aki kijelenti, hogy amit ganyoltal az tulkeppen az alapjaitol szaarr, meg idejetmult es mar ideje lenne lecserelni, es tulajdonkeppen az O kodja az uber, es jo lenne ha az lenne az alapja a tobbinek, stb..., stb... akkor gondolom te is ketszer meggondolnad mielott megszolalsz, mert az elso indulatbol jovo dolgot nem nagyon kultivalna az illeto...

Amugy erdekes, Jaroslav ALSA-javal nem voltak ilyen problemak... Igaz o nem allitotta, hogy az OSS-t ki kell dobni a piccsaba, csak irogattak a patch-eket, s lam-lam idovel az ALSA lett a default hangrendszere a Linux-nak...

Zsiraf

Érdekes, hogy mindenki olyan okos. Én nem vagyok programozó, nem láttam a kódot, nem is érteném.De:

1. A filerendszere tökéletesen működik. Már sok hónappal ezelőtt is így volt. Teljesen élesben is nagyon jól teljesít. Gyorsabb/jobb, mint a vetélytársai.

2. Ha gány a kód(IMHO nem valószínű, főleg, mert azt tartotta a legfontosabbnak, hogy rettentő átlátható legyen, erről szólt a múltkori cikk fele), akkor is figyelembe kellene venni, hogy ez egy filerendszer, tehát sok kárt nem tehet a működő setupokban. Ezt még maga Morton mondta a filerendszerekről a FUSE kapcsán. Ráadásul ha ez lenne a legkevésbe stabil/megbízható része a kernelnek, akkor már rég a linux lenne a szent grál. :D Rakás EXPERIMENTAL, BROKEN meg egyéb szarok mellett elfér bőven.

Bocs a flame jellegért. Kernel nem *****, fejlesztők nem hülyék, de ezt nem értem.

Bye: nightw

A Gentooban mióta az alapértelmezett FS? Mióta van a Gentooban alapértelmezett FS?

Nem, nem erted a lenyeget :) Ponthogy nem kell ujrairni. Ha sima "blokkok lancolt lista alapjan" kepzeled pl a tarolasat a file-nak az egyszeruseg kedveert, akkor elvileg eleg lenne az elso blokkot (ami altalaban max nehany K) ujrairni a file tobbi resze maradhat! Az hogy ilyen nincs, az semmivel sem kevesbe logikus, minthogy a file veget viszont le lehet vagni. Az egyetlen dolog amiert az utobbi van: mert igy szoktuk meg, de semmi nem indokolja hogy miert nem lehetne az elejebol vagy a kozepebol ... A hozzaszolasod is pont azt tamasztja ala hogy te is regies modon viszonyulsz egy filerendszerhez es el sem tudsz kepzelni mas modot hogy az elejebol levagj valamint minthogy ujraird: ezt azert gondolod igy, mert megszoktad hogy a legtobb filerendszer az egyiket tudja a masikat meg nem. Pedig ez nem kotelezo.

Amugy irtam is: Reiser stilusara nem mondtam hogy megnyero lenne, vagyhogy kedves vagy akarmi, csak annyit hogy szigoruan technikai ertelemben lehet attol meg igaza ...

Na ez lehet hogy nem volt ertheto: tehat arrol beszelek hogy egy file a user space fele exportalt API-n keresztul byte-ok sorozata ... Viszont maga a filerendszer (tehat nem userspace-bol pont ez a kulcs) attol tudhat meg "rovidebb utat" ahhoz hogy pl a file elejerol elvegyel. Amit irtal az igaz reszben: ha user space-bol szeretnel a file elejerol torolni valamit akkor ujra kell irnod az egesz file-t ez annak a kovetkezmenye hogy a user space fele mutatott API nem tartalmaz megfelelo hivast ehhez, ez vegulis a VFS model korlatja is, nem veletlen hogy reiser ebbe (is) szererne belenyulni. Filerendszer szinten lehetoseg van azonban ugyanugy torolni a file vegerol mint elejerol vagy kozeperol kb ugyanannyi eroforrast igenybe veve. Nem kell ujrairni az egesz filet pont ez a lenyeg. Csakhat ehhez szakitani kene a tobb evtizedes szemlelettel hogy egy filerendszer "driver" kulso hivasai az egy jol definialt lista amiben ilyen funkcio pl nincs, hanem csak a szokasos dolgok. Az utobbi evekben (sot talan evtizedekben) szinte semmit nem valtozott egy a filerendszerek vilaga, max az on-disk layout (tehat hogy pl merevlemezen fizikailag hogy tarolja a dolgokat) valtozott, hogy hatekonyabb algoritmusok tarolasi modszerek legyenek, de maga az API, tehat vegulis a filerendszer fele adhato muveletek halmaza az mitsem valtozott. Na arrol is lehetne persze vitatkozni hogy szukseg van-e arra hogy valtozzon tehat ez elegge egy komplex tema lehet :)

A FUSE-al is pont az volt a "baj" mint a reiser4-el: tul sok mindenben "szakit" a tradicionalis filerendszerekkel (tobb evtizedes mult stb) es legjobban ez faj nehany fejlesztonek. Mondjuk a FUSE azert mas teszta, de ott is volt nem keves flame az LKML-en, hasonlo rekaciokkal mint pl "ez nem szokvanyos", "ez tiszta mikrokerneles feature, ennek semmi helye a Linuxban", "nem definialhato rendesen a hozzaferesi jogok jelentese" (illetve nem globalis ervenyu ami "szokatlan" egy tradicionalis UNIX rendszerben) stb. Megegyszer kiemelnem hogy en nem reiser stilusat dicserem, hanem csupan azt mondtam hogy abban viszont van nemi igazsag hogy valamikor el kell kezdeni ujban gondolkozni, nem lehet 100 ev mulva is ugyanazt a szokasos vfs API-t hasznalni ...

Érdekes amiket itt írtok.

A 2.6-os sorozatú kernelekben verzióról verzióra megváltoztatják valaminek az API-ját, csak hogy ne legyen egyszerű az élet. Pont a filesystem API-t nem változtatják meg, mert az évek óta úgy van, holott már akkor elavult volt amikor a gondolat csírája sem fogant meg a kitalálója agyában?

Mondjuk ettől a Reiser 4 még lehet össze vissza taknyolva.

A reiser4 lehet osszetaknyolva ettol meg - pontosan - nem tudom :) A VFS API egy erdekes kerdes. Megaztan ne keverd ossze azt, hogy ezt-azt valtoztatgatnak nyilvan mindig, en arra gondoltam hogy alapjaiban a vfs api nem nagyon valtozik, es ez igaz sok mas unix szero OS-sekre is, nem csak a Linux kernel dolgaira. Eleve a user space file api-val is az a gond hogy pl POSIX-ban igazbol nincsenek is olyan dolgok ami tulmutat a "szokasos" alap funkciokon amit mar evtizedek ota tudnak a filerendszerek ... Reiser pont azt vetette fel mar regebben hogy az egesz vfs-t ki kene dobni es a reiser plugin arhitekturaval kene helyettesiteni, ami ala amugy ugyanugy portolni lehetne minden letezo filerendszert, mintahogy ma a vfs "alatt" vannak. Az elonye az lenne, hogy viszont "ujabb" fs implementaciok mint amilyen a reiser4 ki tudna hasznalni a plusz dolgokat is. Amugy ez szerintem is kisse radikalis, es olyan valtozas lenen ami nem biztos hogy igy egyszerre jo oltet (pl stabilitias, kiforrotlansag stb miatt se), en itt csak otletekrol meg koncepciokrol beszelek. A masik dolog ami itt felmerul amugy, hogy sok embert meg is kever a "plugin" szo itt, es olyan pluginekre gondol mint pl egy gaim plugin vagy barmi mas, holott nem errol van szo nyilvan, csak valahogy hivni kell a dolgot :)

Igazabol a masik erdekesseg az, hogy egy csomo dolog amirol Reiser ir is a www.namesys.com oldalon az nyilvan nem uj dolog, es egyre tobb koponyaban merul fel szinten ... Nem kivetel ez alol pl a Microsoft sem. Bar aztan a WinFS-rol vegkepp nem sokat tudok, de sok jel arra mutat, hogy nemsokara "rancfelvarras" kezododhet a piacon ami filerendszereket illeti, es mindenkinek tul kell majd tennie magat azon hogy a regi dolgokkal legalabb reszben szakitani kell. Sajnos az is lehet hogy ez akar hatranyokkal is jarhat, nyilvan minden eremnek ket oldala van :(

1) Az XFS-re is ezt mondták, aztán tedd be SMP-vel egy szépen terhelt MySQL alá és láss csodát! Bár ajánlom, hogy legyen az alaplapon szervízproci/watchdog, ami automatikusan kireseteli. :))))))

Hans Reisernek biztos az a gondja, hogy a 2.6-os széria kezd stabilizálódni és ez tűrhetetlen! :)))))))

Nemtudom veszed-e észre, hogy a reiser4 is elég sok mikorkerneles jegyet hordoz a plugin architektúrájában. A kernel fejlesztők jó része sajnos élből vallási dogmatikus alapon elutasít minden ilyesmit. Nem lennék meglepődve, ha valójában pont ez lenne az egész cirkusznak az oka.

Az legalábbis megfigyelhető, hogy rengeteg olyan dolgot minősítenek bugnak a reiser4-ben (a "fölösleges" indirekciók, meg a vfs-t megkerülő, vagy annak funkcionalitásást részben duplikáló kódok), ami pont azért van benne, hogy a későbbiekben már az api módosítása nélkül lehessen bővíteni a funkciókat.

Nagy kár, hogy a reiser4 gpl only. IMHO Matt Dillon lehet, hogy vevő lenne rá...

A JFS-t is bevették a kernelbe azt mégsem stabil, annyi a memory leak benne, hogy vagy 6 kernel kiadáson keresztül (a 2.4.19-környékén) tele volt a changelog a "[JFS] memory leak fixed"-ekkel ennek ellenére még most is ki lehet akasztani egy komolyabb nagy könyvtár törlésével egy kevés memóriás gépen. Érdekes, akkor nem hezitáltak ennyit rajta, és nem problémáztak, hogy trágya a kód. Ja persze azt a nagy IBM adta, azt meg ugye nem illik visszautasítani. :/

ránéztetek egyébként a reiser4 kódjára? tegnap ugyanis letöltöttem (ugyanis bitkeeper kell ahhoz, hogy azon keresztül nézegesd, nekem meg olyanom nincsen :/ ez egy újabb negatív pont a szememben, VSZ ugyanis jó ha van egy SVN/CVS http-n keresztül brózolható repo, amit a kíváncsi emberkék sec-perc átnézhetnek, anélkül, hogy leszednék a teljes cuccot), hogy átnézzem és őszintén szólva a kód stílusa nekem sem jön be.

azon felül, hogy nem egyezik a kernel kódolási stílusával, nem értem miért gondolják, hogy könnyen olvasható. hacsak azért nem, mert mintha minden egy halom apró funkcióra lett szedve - ami egyébként, ismerve azt, milyen asm kód generálódik a C-s függvényhívásokból és paraméterátadásokból, nyilván performance penalty-val jár.

valaki olyan, aki MEG IS NÉZTE a kódot, kifejtené a véleményét értelmesen, flame nélkül? érdekelne ugyanis mi olyanoknak a véleménye, akik értenek is a kódoláshoz. itt nem is feltétlen a program tartalmára gondolok, hanem csak egyszerűen a programozási stílushoz.

másrészt azt is meg kell jegyeznem, hogy (VSZ) sem a Unix (BSD-re gondolok elsősorban), sem a Linux kernel forráskódja nem szép. nem csak, hogy nem tartom könnyen áttekinthetőnek, de _szerintem_ nem is könnyen olvasható.

ezt addig egyébként észre sem vettem, amíg át nem tekintettem a szinte ismeretlen Plan9 kódot, aminél szebb kódot ritkán látni. egy programozó leül elé és folyamatosan tudja olvasni, minden fennakadás nélkül. nincsen agyon-typedefelve és a cpp makrókban szintén sovány kód ezáltal sokkal könnyebbé válik. nincsen olyan, hogy "na akkor ez most milyen változó is", meg "ez most makró, vagy sem?", azaz nem feltétlen szükséges az, hogy egy programozó leüljön a kernel kód elé és szépen megtanulja az alapokat, kiismerje melyik változó mit rejt, melyik makrót mihez kell használni, a Plan9 kódja ugyanis ilyeneket alig, vagy egyáltalán nem tartalmaz.

Rob Pike ezen írása [herpolhode.com] - részben - erről szól (címe: The Good, the Bad and the Ugly : The Unix Legacy). a tradícionálisan Unixos szemléletekről és azok kevésbé ismert (pláne emlegetett) hátrányairól, a kódok portolhatóságáról, stb. akik képesek nyitott elmével, minden előítélet nélkül átolvasni, azok szerintem örömmel fogják átlapozni az anyagot.

En nem mondtam hogy ez baj :) Hanem azt hogy sok core kernel fejleszto szerint az :) Mindegy, mondjuk egy dolog biztos: lehet, tenyleg nem kene azert egyszerre lecserelni a fel kernelt, megha tfh Reiser-nek igaza is van. Ugyanis azert stabilitas meg miegymas szempontjabol ez tul nagy valtas lenne. De ahogy nezem mar a reiser syscall-rol is lemondott pl Reiser, stb, tehat a megfevo vfs layer ala benyomoritjak azzal meg mindig lehet nyerni (mint barmely mas filerendszerrel) es megteremti a jovobeli nagyobb valtozasok lehetoseget. De tenyleg nem egyszerre kene az egesz vfs-t lecserelni :)

Eljen a blokkokon beluli fragmentalodas!!!!!! :-)))

Zsiraf

p.s.: az elavult file-tarolasnak epp az volt az egyik jo tulajdonsaga, hogy csak az utolso blokk volt toredek... Ezzel lehetett egy csomo dolgot megsporolni... Ha elkezded tordelni a kozbulso blokkokat is, akkor ...

Ez is igaz, es az is, hogy ha megnezed a JFS diffstatot es az akkori leveleket, akkor a JFS a kernel egyeb reszeiben az fs/jfs konyvtaron es az egy darab Makefile-on kivul, ahol a SUBDIRS szeru makro volt *semmit* nem modositott a VFS es egyeb layereken. Magyaran a JFS-t nem hasznalo juzerek fele kockazatmentes volt a merge, aki meg JFS-re alapozott, az lathatta az EXPERIMENTAL flaget. Ezzel szemben a reiser4 eleg sok mindenen valtoztat, nem mondom, hogy szetcseszi azt, de meglehetosen teszteletlen. Ha lenne 2.7, ott jo helye lenne, es most az -mm treeben is nagyon jo helye van (IMHO).

Hat so-so, semmi sincs ingyen :) De ha a peldanal maradva egy tobb gbyte-os file-bol idonkent tetszoleges helyrol/helyre (nem csak a vegen!) be kell szurni/el kell venni darabokat, akkor egyszeruen allati sok nagysagrenddel lassabb ujrairni mindig az egesz filet mint valami hatekonyabb megoldast talalni ... Amugy a reiser3 is csinal ilyesmit (lasd tail/notail mount opcio) igaz nem olyan "szeles korben" mint lehetne, pl ezzel a peldanal is.

Masreszt te is csak tippelsz azzal hogy "... jo tulajdonsaga, hogy csak az utolso blokk volt toredek... Ezzel lehetett egy csomo dolgot megsporolni ...". Ok, en is erre gondolnek eloszor, de biztos vagy benne, hogy ez hatranyara valik egy teljesen uj layout-nak amirol semmit nem tudsz, pl benchmarkokat se, hogy ez tenyleg okoz-e problemat, illetve jobban mondva, hogy tobb hatranya van-e mint elonye?

LGB írta:
> Hat so-so, semmi sincs ingyen :) De ha a peldanal maradva egy tobb gbyte-os
> file-bol idonkent tetszoleges helyrol/helyre (nem csak a vegen!) be kell
> szurni/el kell venni darabokat, akkor egyszeruen allati sok nagysagrenddel
> lassabb ujrairni mindig az egesz filet mint valami hatekonyabb megoldast
> talalni ... Amugy a reiser3 is csinal ilyesmit (lasd tail/notail mount
> opcio) igaz nem olyan "szeles korben" mint lehetne, pl ezzel a peldanal is.

És ha 511 byte-onként beszúrsz 1 Byte-ot mondjuk az 1-től, akkor
kétszeres lesz a helyfoglalás ;)

:) Na azert ennyire ne menjunk bele a konkret algoritmus megtargyalasaba :) Meg nem is ez a lenyeg, ugy erzem. Olyan meg tenyleg nincs hogy valami teljesen feher vagy teljesen fekete, a problema az, hogy gyakorlatilag a filerendszer fogalma mit sem valtozott "evezredek" ota, es legtobben ma is ellenallnak hogy barmi valtozas legyen, akkor is ha kulonosebb technikai ok nincs ra, max a megszokas ...

2. Ha gány a kód(IMHO nem valószínű, főleg, mert azt tartotta a legfontosabbnak, hogy rettentő átlátható legyen, erről szólt a múltkori cikk fele),

Nos ... ha hasonlit pl. a 2.4.18 - as verzio IDE alrendszerenek kodjahoz (ami azert a 2.4.30 korul mar kezdett olyan jegyeket felvenni, mint amibol egyszer talan rendes kod lesz:) akkor eleg ijeszto ez az erv, ha a linux kernel developerek is ganynak tartjak ... :)

Bevallom oszinten, a 2.6 - ot nem neztem meg, nem voltam eleg bator.

XFS - sel az a kedvenc tapasztalatom, mikor anno egy aktualis verzional rairtam egy ekezetes betuket tartalmazo fajlnevet arra a particiora es utana a budos eletbe nem lehetett tobbet mountolni, mert szetfagyott a kernel :)

Remelem azota ezt javitottak ;)

Talan erre szoktak mondani, hogy a linux nem good academic planning, but good engineering.

Én sem mondtam, hogy te azt mondtad. Csak továbbgondoltam amit a mondtál.