cwbe coordinatez:
101
1
102
1546480
1546544
1563643
1565113

ABSOLUT
KYBERIA
permissions
you: r,
system: public
net: yes

neurons

stats|by_visit|by_K
source
tiamat
K|my_K|given_K
last
commanders
polls

total descendants::0
total children::1
show[ 2 | 3] flat
zaujimalo by ma, ci uz mas porieseny vypadok niektorej nody z globalneho namespace. predpokladam, ze data budu na viacerych nodoch aby sa predislo "strate" dat z namespace, otazka je ci to inferno riesi automaticky, alebo to musis poriesit ty.




0000010100000001000001020154648001546544015636430156511301565221
v92
 v92      18.04.2005 - 00:07:30 (modif: ), level: 1, UP   NEW !!CONTENT CHANGED!!
ak niektora noda zdochne skratka jej namespace sa stane nedostupnym so vsetkym co k tomu patri (teda i data adresar sa strati a nebude mozne k nemu pristupovat). redundanciu dat nemam vyriesenu. musim si presne definovat co znamena storage grid a ci je nejaky rozdiel medzi nim a data gridom. Mam v tych pojmoch kusok bordel. momentalne sa sustredujem na rozbehavanie resource gridu ktory bude tvorit zakladny stavebny kamen ostatnych. preto ho treba urobit dobre. vsetko ma svoj cas na vsetko dojde. tento tyzden sa chystam spustit jeho testovaciu prevadzku ale pred tym musim este nejake veci odladit

inak pocas pisania prispevku ma napadla myslienka ako by mohol storage grid fungovat. Napise sa jednoducha aplikacia ktora na zaklade pravidiel bude rozdelovat data do jednolivych user/data adresarov. Moze sa to spravit transparentne tak ze ju nejakym sposobom nabindujem na / globalneho namespaceu a bude robit nejaky filter alebo tak. necham si to prejst hlavou

000001010000000100000102015464800154654401563643015651130156522101565565
juraj
 juraj      18.04.2005 - 09:59:17 (modif: ), level: 2, UP   NEW !!CONTENT CHANGED!!
neviem, toto mi stale pripada ako skrabat sa pravou rukou na lavom uchu.

ako tak pozeram, tak na storage ten inferno moc nie je. chcelo by to nejaky distribuovany filesystem. pretoze to neriesi redundanciu a distribuciu dat :(.

00000101000000010000010201546480015465440156364301565113015652210156556501565765
v92
 v92      18.04.2005 - 11:09:27 (modif: ), level: 3, UP   NEW !!CONTENT CHANGED!!
storage grid mam v TODO liste.inak nemyslim si ze inferno na toto nie je.ano je pravda ze to neriesi sam od seba, ale myslim si ze zas taky velky problem to nebude napisat. kludne by sa to dalo aj cele naskriptovat... .

0000010100000001000001020154648001546544015636430156511301565221015655650156576501567635
linker
 linker      18.04.2005 - 23:57:01 (modif: ), level: 4, UP   NEW !!CONTENT CHANGED!!
Nehovoriac o zatazeni systemu, skriptovanie by som neodporucal z hladiska vykonu. To s tou redundaciou dat je podla mna dost podstatna otazka. Moja predstava bola asi taka:
- vojdem do adresara a mam tam 1TB dat ktore mozem kedykolvek pouzit (proste sa budu na pozadi tahat z inej nody)
- ak ho mam lokalne = casto pouzivane, netaham nic
- vsetko co tam nakopirujem sa zahrnie do globalneho namespace
- vyriesi to redundanciu

0000010100000001000001020154648001546544015636430156511301565221015655650156576501565892
juraj
 juraj      18.04.2005 - 11:52:20 (modif: ), level: 4, UP   NEW !!CONTENT CHANGED!!
no, to si neviem moc predstavit. vzhladom na to, kolko trvalo nieco take vobec naprogramovat, tak pochybujem, ze pri akomkolvek skvelom dizajne systemu nieco taketo pojde naskriptovat....

vies kolko situacii to musi riesit?