DBFS

Azt mondja el nekem valaki, hogy miert jo, ha az adatbazis cucc a filrendszerbe van beleegetve? Miert nem jo az userspace-ben?

Nekem valahogy az a fixa idealom hogy userspaceban lenyegesen rugalmasabban megoldhato a dolog.. Ok, annyi talan kellene kernelbe hogy fileokhoz mindenfele meta-infot lehessen hozzafuzni, de a tobbit mar siman meg lehet csinalni kernelen kivul, mindenfele kafa guit aggatva ra, es megtartva a megszokott filerendszer felepitest/kinezetet/etc...

Szoval tok kivancsi lennek ra, hogy tulajdonkeppen miert is gondoljak emberek azt, hogy ezek a kezdemenyezesek jok, es miert?

Imho pl azert, mert ha (majd 1x valamikor) az alkalmazasok is hasznalni szeretnek ezeket a metainformaciokat, akkor nem kell egy valamilyen wrapper hozzajuk, amik egy masik userspace cuccon keresztul legyujti nekik. Vegso soron egyszer majd a metainformaciok alapjan lehet metafajlokat kesziteni (semak, sablonok, xml, mittomen alapjan), amikhez kozvetlenul a kernelen keresztul hozzafernek a metaalkalmazasok :)

Mondjuk öszintén szólva nem tudom, hogy mit gondoljak. Én már régebb óta (WinFS és Reiser4 előtt) spekulálok azon, hogy mi lehetne továbblépés a jelenlegi fájlrendszer szemantikából. Valami továbblépés kellene. Amiket a Winfs és a DBFS csinál az tulajdonképpen egy spéci locate beleintegrálása. Megjegyzem a DBFS teljesen userspace, és ha igazak a kiszivárogtatott infók, akkor a Winfs is.

A Reiser4 már kicsit más tészta. Ez a fájl/könyvtár fogalmán való változtatásokat is lehetővé tesz. Ettől függetlenül a megvalósítandó célok terén jelentős átfedés van. (Erre a keyword hozzárendelésen alapuló csoportosítás és visszakeresésre gondolok)

Amit viszont én találtam ki, az teljesen más. Lényegében a Reiser4 áll hozzá legközelebb, de az én elképzelésem sokkal radikálisabb annál. Egyszer majd a közeljövőben veszem a fáradtságot, hogy leírjam a gondolataimat erről. Annyit elöljáróban, hogy a fájlformátumok teljes felszámolása a célom, így mindenféle adatmanipuláció, amihez most formátumonként külön editorprogramok kellenek, az most mind egyszerű fájlműveletté válik. Lényegében a fájlok belső struktúráját teljesen meztelenül kiraknám. Természetesen lenne asszociatív/dekalratív illesztés, amivel a belső sturktúra egyes elemei alapján is lehetne azonosítani. Persze ezzel minden kompatibilitás megszűnne a világ többi részével. A Reiser4 ehhez annyiban áll közel, hogy elvileg lehetővé teszi reguláris fájlok könyvtárként megnyitását. (Ebből volt a para a múltkor a LKML-en)

Őrült vagyok? Lehetséges. :) Gondolatkisérletnek azért jó lehet.

Erre kene egy szabvany vagy hasonlo, hogy hogyan kell ezeket osszegyujteni. Es azt akkor meg lehet csinalni userspaceban, lehetnenek alternativ libek, stb...

Ami akarja, hasznalja, aki nem, nem. Es raadasul egy ilyen megoldas egyszerubben portolhato oprendszerek kozott is.

Amúgy most döbbenek csak le, a Winfs csak 2007-re várható, ez viszont már most ITT VAN és MŰKÖDIK! Igaz egyenlőre csak KDE alatt, de úgy tünik lesz folytatása.

A winfs elvileg így működne. Az NTFS-ben most is megtalálható, fájlhoz kapcsolható streameket használná arra, hogy a tageket tárolja. A tagek használata (létrehozásnál) kötelező lenne, ennyiben lenne mindössze kernelspace a dolog.

Egy ilyesmi a free rendszereken is jo lenne, ennek van ertelme :)

Dehogy az egesz kernelben legyen, az csoppet tulzas imho.

Voltak, vannak a gnome vilagaban is hasonlo fejlesztesek, elkepzelesek.

Storage: http://www.gnome.org/~seth/storage/

Beagle: http://www.gnome.org/projects/beagle

Beagle kepekkel (nagy kepekkel): http://nat.org/beagle/

Valami csak lesz beloluk.

Lásd $topic! :)

Ha már filozofálgatunk: ha belegondoltok, ez lényegében csak visszatérés az eredeti ötlethez, a könyvtárstuktúrához. Amit most könyvárstuktúrának hívunk, az már igen messze került az eredeti céltól, a file-ok könyvárszerű rendezésétől.Ha bemész egy könytárba (igaziba) egy dokumentumért, az így néz ki:

- Mit szerete kölcsönözni? Könyvet, hanglemezt, filmet?

- Egy könyvet, X írótól, mindegy melyiket, csak a Z ne legyen, mert azt már olvastam, és egy lemezt I-től, a címére pontosan nem emélkszem de valami J volt benne, azt hiszem K körül adták ki.

Na most melyik hasnlít ehhez jobban:

1) - Volt itt egy PDF ettől a faszitől, azt hiszem, a Documents-ben van, a download-ban. Ja nem, azt a Petitől másoltam át, akkor a /mnt/rack/win-e/petitol-ben van valahol, vagy a docs-ban, vagy az uj-ban. Nemtom, keress rá. Hogyhogy nincs meg, ott kell lennie, várjá, lehet nem is PDF-ben van, hanem DOC-ban. Megvan az az album is, hát, vagy az _mp3z-ban, vagy a zene, vagy a music, vagy a 200407 könyvárban, legegyszerűbb ha rákeresel, keress rá az összes vinyón, mert nem tudom melyiken van. Nem gáz, k*rva gyorsak, négy-öt milisec a seektime-juk, úgyhogy egy ilyen keresés is lefut 2-3 perc alatt...

2) - SELECT type=doc, auth=X, title=NOT Z; SELECT type=music, auth=I, title=*~J*, date=NEAR K;

Újabb belegondolni való: egy csomó törekvés volt eddig is, hogy a hagyomásnyos filerendszerekben megvalósítsanak egy ilyen jellegű tárolást: pl. a tradicionális Unix Filesystem-nek is az a célja, hogy megakadályozza a könyvtárak elburjánzását, viszonylag szabványos, egyszerű, könnyen megjegyezhető cimkével jelöljön meg, és jelleg szerint csoportosítva tároljon file-okat.

(Mielőtt túl nagyra dagadna az a kebel: a saját homejában akkora káoszt csinálhat az ember, amekkorát csak akar).

Az pedig, hogy ezt a kernelspace-ben filesystem driverben, vagy userspace beli programban érdemesebb-e implementálni, már szakmai kérdés. Ezt dönték el nálam okosabbak. Bár gyanítom, hogy még ők sem nagyon fognak tudni dönteni, hanem majd az:

A) Idő

B) Gates

húú de megszaladt az agyam, bocsi.... :)

Sziasztok!

"DBFS"?

Nem hasonló ez a "WinFS"-hez?

Mert ha igen, akkor lesz honnét "lenyúlni" az ötleteket (szokás szerint). Lévén, hogy a nyílt forrást bárki olvashatja. A zárt kódot meg csak egy szűk réteg...

Az ilyen peldakon keresztul lehet lemerni hogy az Opensource kozosseg mennyivel gyorsabban es rugalmasabban reagal a kihivasokra. :)

Szerintem a MS-nak mar most megvannak a sajat otletei, es ez a DBFS nekik mar nem fog tul nagy ujdonsagot mutatni, es eleg specifikus ahhoz hogy ne legyen illesztheto az o rendszerukhoz. Otleteket ettol meg merithetnek belole, de idoben akkor is le lesznek maradva az implementacioval. :)

Inkabb leved valamilyen eljarast, ami alapjan a dbfs hasznaloktol penzt lehet kerni. :(

Jó pár évvel ezelött Larry bácsi azt mondta, hogy mi a töknek ide filerendszer, tegyétek az egészet adatbáziskezelöbe!

Természetesen az Oracle-re gondolt. :-)

Aztán továbbgondolta a dolgot, és azt is mondta, hogy ha már minden adatbáziskezelőben van, nincs is szükség Windowsra, csak egy kicsi OS szerű rétegre, ami a vashoz illeszti az Oracle-t.

Horribile dictu!

Megjelent a szemeim előtt egy MSDOS, Oracle-lel mögötte...

Nem a Winfs várható 2007-re, hanem a Longhorn fedőnéven futó új operációs rendszer kiadása... Így kicsit ferdítésnek találom a hozzászólásodat. A Winfs nagyjából már most is kész van, csak a hozzá kapcsolódó egyéb megoldások váratnak magukra és a meglehetősen hosszú tesztelési időszak. Az Open Source alternatíváknál sem hiszem, hogy hamarabb lesz belőle produktív kiadás... (Az csak egy dolog, hogy a Reiser4 bekerül a kernelbe, de a userland programok mikor lesznek felkészítve arra, hogy kihasználják az általa nyújtott lehetőségeket? Az új Windowsban lévő alkalmazások 2007-re fel lesznek rá készítve.)

Ehm. Az Open Source megoldások sajnos még mindig javarészt a "követő technológia" címszó alá írhatók. Nem is értem, hogy mi alapján gondolod azt, hogy gyorsabban reagálnak a kihívásokra...

Ne nevettesd már ki magad azzal a gondolattal, hogy a Microsoft a DBFS fájlrendszerből fog bármit is lopni. A WinFS specifikációja már évek óta kész a Microsoftnál és a WinFS implementálása is. Az API-t leíró dokumentumok már jóideje elérhetők a WinFS SDK-ban [msdn.microsoft.com].

Emberek ébredjetek már fel. Az Open Source kullog a Microsoft után és nem fordítva...

Hi!

Afaik a reiser4-ben az a plane, hogy pindurka adatmennyisegeket tarol el hatekonyan a bazi nagy winyokon. Tovabba elvonatkoztatja a fajl / konyvtar parost egy olyan alapelemme, ami mindig tartalmazhat tovabbi dolgokat.

Kb. eddig van kesz. Ami most jon, az olyan pluginek keszitese, amik ezt hasznalva csinalnak ertelmes dolgokat. Szerintem egy ilyen szintnek kernel space-ben a helye, asszem a pluginok mar user space, plane az ezt tovabb hasznosito cuccok.

Tehat a reiser4 _leegyszerusit_, tulajdonkeppen van benne 1 fajta alapobjektum, aminek a konkretabb hasznositasa varat magara. Hans Reisernek 11 evebe tellett idaig eljutni, tehat vszinuleg nem osszecsapott munka. Es amitol Hans igazan porog az az, hogy vegre kesz az alap, most johet a moka!

udv,

Greg

Én úgy tudom (jó rendben, a The Register nevű mindig igazmondó "ténylap" ;) szerint), hogy a Longhorn megjelenését 2006-ra tervezik és nem fogja tartalmazni a WinFs-t mert még nem lesz kész akkorra. Majd 2007-re tervezik egy add-on pack formájában. És állítólag nem csak a Longhornhoz, hanem "korábbi" oprendszerekhez (winxp?) is el fogják készíteni.

"Ilyesmit ... hallottam ... én." :)

Megjegyzem ebben a konstrukcióban a Microsoftnak igen komoly gondjai lesznek az alkalmazások általi támogatottság szempontjából.

Nem teljesen ferdítés ez, inkább bulvárhírnek nevezném.

Szerintem inkább attól pörög, hogy a Microsoft ne szabadalmaztassa el az orruk elől amit ő kifejlesztett. :(

Hihi, elég érdekes lenne... Gondolj bele, add-on pack formájában és winxp-hez is? Szinte az egész Windows XP "userland"-et le kell cserélni ahoz, hogy kihasználja a WinFS megoldásait. Nagyobb lenne az "add-on pack", mint a Windows XP... Másodsorban rendkívül nehéz egy ilyen monumentális megoldást elkészíteni úgy, hogy ilyen patch jellegű formában utána illeszteni lehessen minden rendszerhez. A Service Pack 2 sem véletlenül késett annyit...