Keresek egy file rendszert...

Fórumok

Fontos: A topic egy elmeleti jatszadozas. Nem keresek masik megoldast a problemamra, kifejezetten arra lennek kivancsi, hogy letezik-e ilyen file rendszer, ami az igenyeimet kielegiti (a tobb szem tobbet lat alapon, mivel en nem talaltam megfelelot).

Problema leirasa:
Adott N server, amik egy FC SAN-bol kiajanlott kozos disk-et latnak. Egy olyan file rendszert keresek, ami megfelel a kovetkezo kriteriumoknak:
* Fel lehet mountolni minden serveren egyszerre ugy, hogy kizarolag egy RW mount tortenik a tobbi mind RO
* A server, ami RW-be mountolja NEM rendelkezik semmi halozattal
* A szerverek nem kepesek kommunikalni egymassal (nincs halozat, nincs soros kabel, nincs semmi :) )
* az RW node altal irt adatok meghatarozott idon belul lathatoak az RO node-okon (akkor is, ha eppen ugyanazt a konyvtarat listazzak ki mint 1 masodpeecel ezelott (tehat a kernel tudja "valahogyan", hogy a Page cache mar invalid))
* Linux-on hasznalhato es Open Source
(* plusz egy raadas: jo volna ha valami journaling fs lenne)

Ha nem letezik, akkor ennek ki, milyen technikai okat latja?

NEM MUKODIK:
* NFS, CIFS, GlusterFS, CephFS, GFS1/2, OCFS1/2 etc.: halozat szukseges hozzajuk
* Ext2/3/4, XFS es tarsaik: Nem lehet tobbszor felmountolni oket
* VMFS: zart, hatalmas limitaciok linux alatt, nem skalazodik elegge

Szerk1:
Elindultunk egy jo iranyba es koszonhetoen a commenteknek folyamatosan finomitom a kriteriumokat. Osszeszedtem a kilott FS-eket is, es az okat a kilovesnek

Szerk2:
Mondjuk ugy, ha az XFS-t fel lehetne mountolni tobbszor (1 RW es N RO) akkor az lenne a tokeletes FS-em. (snapshotos trukkozes a kovetkezo level aljan nem jatszik mivel folyamatos iras van)

Szerk3:
Szoval az eddig osszegyujtottek alapjan egy olyan OS-t keresunk, aminel:
* kikapcsolhato a kernel write cache hasznalata (lsd sync option ext2/3/4-nel) vagy optimalis esetben valahogyan garantalni tudja, hogy csak "osszefuggo modositasok" talalhatoak a dirty page cache-ben
* read eseteben kikeruli a kernel read cache-et vagy optimalis esetben valahogyan tudja, hogy iras tortent az RW node-on ezert az adot page invalid a cache-ben
* az irasnal a file lockolasa megoldott a disk-en keresztul

Hozzászólások

"A szerverek (es ugye igy az FS) kizarolag a SAN-on keresztul kepesek kommunikalni egymassal (nincs halozat, nincs soros kabel, nincs semmi :) )"
Elég, ha csak az egyik szerver felől a többi felé megy a kommunikáció és vissza nem? A többi szerver meg nem is tud egymásról. Mert ha csak "írásban" kommunikálnak és csak az egyik tud írni, a többi csak olvasni, akkor ez egyirányú információáramlás.
Szóval gondold ezt át! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Most akkor az jó lenne, hogy 9p fájlrendszert felcsatolsz N-szer RO módban, egyszer RW módban?
És akkor kéne valami, ami mindezt automatizálja?

Mi a probléma? Mármint mit szeretnél ezzel megoldani?
És mennyire lesz probléma, hogy az írásról csak késve értesülnek a többiek?
Vagy pont a szinkront szeretnéd megoldani?

GT

Sosem hallottam meg a 9p fs-rol. Mivel a kovetkezo idezet a wikipediarol azt mondja, hogy alapvetoen ez egy halozati protokol ezert ez nem megoldas:
"9P (or the Plan 9 Filesystem Protocol or Styx) is a network protocol"

Mint irtam a kezdo topicban nem megoldast keresek egy problemara. A problemat megoldottuk, de ugy gondolom, hogyha letezne az altalam megalmodott FS akkor az jobb megoldas lenne. Sokszor tortent mar velem hogy kitalaltam vmit, azt gondoltam kva nagy otlet, korul neztem es mar vki megcsinalta vagy nagyon kozel volt hozza. Ebben az esetben nem talalom a kesz termeket.

Pontositottam a kiirast, hogy egyertelmubb legyen, hogy "normal" halozat nem jatszik.

van ilyen, sot tobbet is tud, vmfs-nek hivjak

Clusterfs-eken kivul szerintem csak nfs.
De gondolom te lokalis fs-re gondoltal.

Oke megprobalom utoljara, legyszi olvassd el nyugodtan, odafigyeloen. Az adott kriteriumoknak megfelelo file rendszert keresek, nem pedig egy masik megoldast.

Mint fentebb irtam, van megoldas a valos eletbeli problemankra (NFS-t hasznalunk jelenleg egy hierarchikus FS felett ;) ) ez kizaroan egy elmeleti jatszadozas

Elso volt, amit megneztem, amikor az otlet az eszembe jutott :)

En ugy tudom, hogy nem lehet. Mivel nem vagyok egy kernel level fs hacker lehet, hogy vki meg tud cafolni, ezert leirom azokat a problemakat amirol en tudok (es a megoldasokat amit en ismerek rajuk (hatha rosszak :) )):
1) Journal replay, akkor is amikor ro-ban mountolod: Ez ugye akkor jatszik, ha ugy tunik, hogy nem tisztan lett umountolva (ez barmikor lehet koszonhetoen az RW node dirty cache-nek (lasd kesobbi problema)). Ez elvileg megoldhato a noload mount option-nel az RO node-on, igy hagyjuk, hogy az RW node kezelje a problemakat a journal segitsegevel.

2) Dirty page cache az RW OS-nel (bar ez nem direktben az FS problemaja): Ugye by default a kernel nem ir ki mindent a diskre egybol hanem a memoriaban tarolja oket (Dirty Page Cache). Bar sokaig azt gondoltam, hogy ezt nem lehet kikapcsolni FS szinten (csak ha az app DirectIO-t hasznal vagy megfelelo utemben hivja a fsync()-et) de most ugy tunik szamomra, hogy a sync mount option megis minden megold ebben a problemakorben (bar elmeletben egy erre tervezett FS/kernel paros akar hasznalhatna dirty page cache-t is (kivancsi vok hogy a VMFS ezt hogy oldja meg))

3) VFS cache a RO-oldali OS-eknel. Bar ez sem direktben FS problema, de erre nem tudok megoldast jelenleg ext2/3/4 eseteben. Ugye az OS hasznal read cache-t amit pl a echo 3 > /proc/sys/vm/drop_caches parancsal el is tudunk dobni. Ezt kikapcsolni nem lehet es az EXT2/3/4 nem tudja ezt megkerulni. Mivel az iras nem az RO OS-en tortenik a kernel azt gondolja majd, hogy a cache-ben levo page-ek meg jok es azokat fogja visszaadni.

4) Dap kollega altal felvetett locking problema is fennal ilyen FS-ek eseteben: "Egy általános fájlrendszer sok összetett adatstruktúraval dolgozik, amit nem egy atomic read-del olvas fel, ergo nem biztos hogy az konzisztens lesz. Lockolni kell az írás idejére". Erre nincs megoldas jelenleg Ext2/3/4, XFS eseteben

Szerk: OK, szoval gondolom a fentebb emlitett okoknak (is) koszonhetoen VMware nem hasznal (legalabbis 2011-ben) cache-t a VMFS-ben (se read se write cache-t): http://www.yellow-bricks.com/2011/04/07/mythbusters-esxesxi-caching-io/

Szerk2: Bar azt nem irtam le, de gondolom a 2-es es 3-as problemanak a kovetkezmenye egyertelmu: rossz file tartalom, mar torolt file-ok olvasasa stb.

Szerk3: hozzaadtam Dap kollega lockolasi problemajat 4-es pontkent

> RW node altal irt adatok meghatarozott idon belul lathatoak az RO node-okon
Mi az a meghatározott idő? 1 mp, 1 óra, 1 nap..?

Ehhez legközelebb az append-only logfs-ek (log-structured filesystem) állnak. A cache invalidálás ott is megoldandó probléma, de legalább lockolni nem kell.

Na erre kiváncsi vagyok... Ez egy pofon egyszerű probléma, kell hogy legyen megoldás rá. Csilivili cluster fs-ek?

Szerk3 a nyito posztban (hatha segit valakinek :) )

Az R/W cache kikapcsolása csak félmegoldás.

Egy általános fájlrendszer sok összetett adatstruktúraval dolgozik, amit nem egy atomic read-del olvas fel, ergo nem biztos hogy az konzisztens lesz. Lockolni kell az írás idejére vagy logfs kell (bár elméletben ott is kell lock, de ott egyszerűbb a mechanizmus).

Ez erdekes felvetes (modositottam a szerk3-at emiatt).
Normal, lokalis FS (XFS, EXT2/3/4) eseten (gondolom) ezt kernel szinten oldjak meg. ClusterFS-ek eseten distributed locking-al (es ehhez hasznaljak altalaban a TCP stack-et).

A mi esetunkben ezt disk-en keresztuli lockolassal kellene megoldani.

En ugy gondolom, hogy technikailag meg mingid lehetseges lehet egy ilyen FS letezese.

Probaltam elkerulni, hogy leirjam, mert mindenki arra fog fokuszalni, hogy hogyan oldana meg. De mint irtam parszor nem ez a lenyege a topic-nak. Mivel ugy tunik, hogy a kivant FS-em nem letezik, ezert leirom a mi projectunket es meg par use case-t amit el tudok kepzelni.

Szoval nalunk a project az, hogy tobb station kuld adatot egy kozponti DC-be. Ezen az adaton (jelenleg kb 30GB/nap) kozponti serverek jol parallelizalhato nagy szamitasigenyu feladatokat vegeznek. Mivel az algoritmus valtozik/optimalizalodik neha ujra kell kezdeni az egesz data set-en (jelenleg kozel 1PB) vagy csak egy reszen. Mint lathato, mondhatjuk, hogy 1 host ir es a tobbi olvassa az adatot. Jelenleg NFS-el van megoldva de gondoltam ha letezne egy ilyen FS azzal elkerulheto a plusz egy, halozati layer. ClusterFS-ekkel a problema, hogy neha (rekalkulacioknal) tobb server is beszall es ez sok esetben nem annyira egyszeru megoldani. Valamint nem nyujtana jobb megoldast mint az NFS. DistributedFS nem szukseges mivel van high-end storage csilliokert es nem kell software-es megoldason gondolkodnunk. Legegyszerubb az lenne ha csak siman felmountolnam az fs-t az uj server-eken es mehetne is a kalkulacio.

Igazabol barmilyen use case-nel lehetne hasznositani ahol ClusterFS-t hasznalnak de eleg lenne ha csak 1 server irna:
* nagy forgalmu weboldal, ahol tobb server szolgalja ki a tartalmat
* IaaS kornyezetben uj VM-ek inditasanal

Mint fentebb irtam, elso ranezesre egyszeru dolognak tunt es nem ertettem, hogy miert nem talalom ezt az FS-t. Azt gondoltam, hogy a a distributed locking a clusterfs-eknel csak azert kell mert tobb host is irhat egyszerre a file rendszerre es elkerulheto lenne ha csak egy irhatna. Ugy tunik a distributed locking ebben az esetben sem megkerulheto es valoszinu, hogy a TCP/IP stack hasznalata erre jobb megoldas, mint a disk-en keresztuli lock-ing, ezert nem talalom ezt az FS-t :)

mint a disk-en keresztuli lock-ing

Ezt már sokadszorra írod, csak nem értem, hogy mi az alapja annak, hogy ilyesmiről beszélsz. A diszktartalmon keresztül lehetne lockolást csinálni, csak baromira lassú lesz. Az meg, hogy a diszk firmware-ben implementáljanak valami szofisztikált lockolást, hát lásd be, hogy ez azért az irreális kategóriája... és hogy menne ez? Valamelyik FS kitalálói megkérik az összes gyártót, hogy csinálják meg? Vagy csak egy diszktípussal fog működni az a FS? Na ennek aztán nagy piaca lenne...

Szóval hogyan, milyen jelenleg is létező diszkművelettel gondoltál lockolást csinálni? Mert leginkább azért nem létezik ilyen FS, mert nem létezik ez a fajta lockolás sem... így azt várni, hogy "majd akkor valaki megírja" erőteljesen veszett fejsze nyele.

OpenVMS, 1980-2015-...

>b-but muh superior bazarlinyux

tough