mboost-dp1
unknown
Hmmm, spændende ide, at udnytte P2P teknologien på denne måde.
Hvordan mon sådanne et system vil virke i en virksomhed hvor alle udviklere har laptop's ? pludselig forsvinder mange filer fra nettet, når folk går hjem.
Fra CW's artikel:
Systemet er i et simuleret netværk testet til at kunne yde 160 Mbit/s i et 10 Mbit/s netværk med 100 Mbit/s backbone.
Hmm 160 Mbit/s på en 10 Mbit/s linie, det er da meget godt klaret.
Eller mener de måske at det er ialt imellem alle clienter ?
For så er 160 Mbit/s å¨en 100 Mbit/s backbone også rimeligt godt klaret.
Eller mener de ialt for et komplet netværk hvor nogle går over backbone og andre kun lige via den lokale switch osv, ?
Hvordan mon sådanne et system vil virke i en virksomhed hvor alle udviklere har laptop's ? pludselig forsvinder mange filer fra nettet, når folk går hjem.
Fra CW's artikel:
Systemet er i et simuleret netværk testet til at kunne yde 160 Mbit/s i et 10 Mbit/s netværk med 100 Mbit/s backbone.
Hmm 160 Mbit/s på en 10 Mbit/s linie, det er da meget godt klaret.
Eller mener de måske at det er ialt imellem alle clienter ?
For så er 160 Mbit/s å¨en 100 Mbit/s backbone også rimeligt godt klaret.
Eller mener de ialt for et komplet netværk hvor nogle går over backbone og andre kun lige via den lokale switch osv, ?
"Punkter som sikkerhed eller stabilitet hvis en eller mange pc'er slukkes, bliver dog ikke nævnt."
I artiklen står der vist at alle filer bliver gemt 4 forskellige steder, men der vil dog stadig være et problem efter kl 16 :P
I artiklen står der vist at alle filer bliver gemt 4 forskellige steder, men der vil dog stadig være et problem efter kl 16 :P
Hehe.. Det kunne da være fedt, hvis de kunne lave noget, der feks, kunne undersøge om en comp var blevet slukket, og så lave de filer som var på den comp, på nogle andre comps.!
Men hvad så som i siger... Kl 16.... lol
Der er helt klart muligheder i dette.. Der skal bare laves noget ved kl 16 problemet :-)
Hygge.
Men hvad så som i siger... Kl 16.... lol
Der er helt klart muligheder i dette.. Der skal bare laves noget ved kl 16 problemet :-)
Hygge.
Idéen er der meget god, men jeg ser nu også en række store svagheder.
Udover problemet med laptops der kobles af og på nettet, hvad så hvis de kobler på derhjemme med en vpn-forbindelser, skal de så 'lege' med, det bliver ikke sjovt at hente den fil der ligger på den laptop.
For desktops, tja så er det jo mere eller mindre påkrævet at de skal stå tændt konstant. Skal systemet virke med god redundans, så skal man sikkert op på et betragteligt antalt computere. Det vil give en strømregning der sikkert hurtigt kan betale en filserver.
Systemet kan heller ikke andet end give en væsentlig højere belastning på netværket. For nogle virksomheder kan det måske ikke mærkes, men arbejder man meget med store tunge filer, tja så er det næppe sjovt at den samme 1GB video reelt skal skrives 3-4-5 steder.
Det kunne måske mere bruges som en erstatning på den måde at man har 10 almindelige desktops i serverrummet, der så bruger det distribuerede filsystem på dem. Uden lige at grave i det, findes sådan en metode så ikke allerede?
Udover problemet med laptops der kobles af og på nettet, hvad så hvis de kobler på derhjemme med en vpn-forbindelser, skal de så 'lege' med, det bliver ikke sjovt at hente den fil der ligger på den laptop.
For desktops, tja så er det jo mere eller mindre påkrævet at de skal stå tændt konstant. Skal systemet virke med god redundans, så skal man sikkert op på et betragteligt antalt computere. Det vil give en strømregning der sikkert hurtigt kan betale en filserver.
Systemet kan heller ikke andet end give en væsentlig højere belastning på netværket. For nogle virksomheder kan det måske ikke mærkes, men arbejder man meget med store tunge filer, tja så er det næppe sjovt at den samme 1GB video reelt skal skrives 3-4-5 steder.
Det kunne måske mere bruges som en erstatning på den måde at man har 10 almindelige desktops i serverrummet, der så bruger det distribuerede filsystem på dem. Uden lige at grave i det, findes sådan en metode så ikke allerede?
Til bærbare er det nok ikke den bedste løsning, men for desktops der er fast på et netværk er det glimrende.
Men man kunne kombinere det med Bloom filter til hash værdier, så alle ved med en hvis sandsynlighed (yes-biased med hensyn til at ikke findes ), hvad andre computere har og tænder computeren hvis der er brug for data'ene.
Men man kunne kombinere det med Bloom filter til hash værdier, så alle ved med en hvis sandsynlighed (yes-biased med hensyn til at ikke findes ), hvad andre computere har og tænder computeren hvis der er brug for data'ene.
http://www.openafs.org/
Er det ikke lidt samme?
Forstår ikke hvorfor folk altid skal trække p2p koncepterne ind i det her, p2p er enormt ineffektivt, fordelen ved p2p er at netværket er ret svært at bryde ned. Men et p2p filsystem lyder nu ikke specielt interessant set fra mit perspektiv, hvor ville det være interessant henne?
Er det ikke lidt samme?
Forstår ikke hvorfor folk altid skal trække p2p koncepterne ind i det her, p2p er enormt ineffektivt, fordelen ved p2p er at netværket er ret svært at bryde ned. Men et p2p filsystem lyder nu ikke specielt interessant set fra mit perspektiv, hvor ville det være interessant henne?
Desuden bliver ydelsen på en bærbar's harddisk væsentligt dårligere, hvis der helle tiden skal gemmes på den. Det bliver bestemt ikke sjovt at arbejde på den.
re #6
nej,
gider ikke at skrive mer, skal spille diablo
http://intern.kom.auc.dk/net/doc/studnet/windows/a...
nej,
gider ikke at skrive mer, skal spille diablo
http://intern.kom.auc.dk/net/doc/studnet/windows/a...
Kanon fed ide. Der hvor jeg arbejder er der mange PC'er som har meget større harddisk, end der kan bruges. Det er jo nærmest umuligt at få harddiske på mindre end 80GB i dag. (kan i hvertfald dårligt betale sig)
Til bærebare computere er det nok en del uholdbart, som i nævner, men artiklen nævnte jo heller ikke at det var beregnet dertil.
Man kunne jo også stadig have en server stående, og så bare bruge klienterne til redundant data samt ekstra hastighed. Dermed kan man spare meget på serveren og netværket.
Til bærebare computere er det nok en del uholdbart, som i nævner, men artiklen nævnte jo heller ikke at det var beregnet dertil.
Man kunne jo også stadig have en server stående, og så bare bruge klienterne til redundant data samt ekstra hastighed. Dermed kan man spare meget på serveren og netværket.
men hvad med sikkerheden...
hvis en fil ligger en 4-5 steder kan man vel også få fat på dem de steder. en fil man normalt ikke har adgang til ligger lige pludselig på ens maskine hvor man så meget nemt kan rode rundt med den...
så vil jeg hellere have en filserver hvor jeg kan styre hvem der har adgang både til selve serveren og til filerne på den
hvis en fil ligger en 4-5 steder kan man vel også få fat på dem de steder. en fil man normalt ikke har adgang til ligger lige pludselig på ens maskine hvor man så meget nemt kan rode rundt med den...
så vil jeg hellere have en filserver hvor jeg kan styre hvem der har adgang både til selve serveren og til filerne på den
Der opstår vel også et problem i virksomheder, hvor der skal lagres jævnligt på hver computer. Hvis der er meget mere en 1 lagring af gange, bliver det ikke sjovt at arbejde ved den pågældende computer..
Man må håbe at der er tænkt på en eller anden form for sikkerhed, for hvis en tilfældig pc bliver sjålet, så har tyvene pludselig adgang til alt data også.
Det må også være temmeligt irriterende at ens harddisk hele tiden bliver brugt og evt. sløver maskinen ned. Maskinerne skal vel også være identiske, eller er det laveste fællesnævner der er sætter max. kapaciteten for systemet?
Det må også være temmeligt irriterende at ens harddisk hele tiden bliver brugt og evt. sløver maskinen ned. Maskinerne skal vel også være identiske, eller er det laveste fællesnævner der er sætter max. kapaciteten for systemet?
Den følger vel bare almindelige p2p standarder. den sløveste maskine er den hurtigste.
Kunne faktisk være ret interessant hvis det gav udbyderene en helvedes masse mere harddisk plads. Så den fx. gemte alt det brugerene downloadede. Og downloadede en bruger den samme fil, ville den hente den lokalt(fra centralen) med højere hastigheder.
Kunne faktisk være ret interessant hvis det gav udbyderene en helvedes masse mere harddisk plads. Så den fx. gemte alt det brugerene downloadede. Og downloadede en bruger den samme fil, ville den hente den lokalt(fra centralen) med højere hastigheder.
så kunne man måske endda også udvidde systemet til alle isp'ens kunder? :> måske ikke lige dem med dail-up :)
men et eller andet sted er det da lidt farligt når man spanner en fil i så mange bidder, er der så ikke ret stor risiko for korruperet data? :>
men et eller andet sted er det da lidt farligt når man spanner en fil i så mange bidder, er der så ikke ret stor risiko for korruperet data? :>
Jeg vil prøve at besvare nogle af Jers spørgsmål og kommentarer:
#1: "Eller mener de måske at det er ialt imellem alle clienter ?
For så er 160 Mbit/s å¨en 100 Mbit/s backbone også rimeligt godt klaret."
Test netværket bestod af 96 computere, 4 stk. 24 ports 10 Mbit switche koblet op til en 100 Mbit backbone.
Setup: http://www.cs.auc.dk/~lau/heurika/test-network.png
Testresultatet stammer så fra det samlede hastighed i hele systemet. Grunden til at vi kunne nå over de 100 Mbit som backbonen tillader er at computerne også kan snakke internt i hver switch.
#2: Man kan specificere replikationskonstanten som systemet bruger (altså det antal kopier der er af hver block/fil i systemet).
#4: Det du nævner med strømforbruget af computere i en virksomhed er ikke helt rigtigt. I mange virksomheder slukkes computerne ikke om natten, da der så fx. køres sikkerhedsopdateringer ol.
Der er selvfølgelig scenarier som netværket ikke er så god til at håndtere. Eksemplet du kommer med lyder noget kundtigt, da man sjælden vil skrive store data mængder med korte intervaller (fx. ved videoredigering bruges ofte specielle A/V diske).
#6: Det er faktisk lige omvendt. Det er selvfølgelig noget overhead i et P2P system, da computerne skal snakke sammen, men ellers kan man opnå meget højere udnyttelse af netværket data alle maskiner er servere og derfor tilbyder filer. Det der er stor overhead i er når det skrives, da det skal replikeres i et antal eksemplarer, men det er nødvendigt for at opnå den høje tilgængelighed af filerne.
#7: Det skulle ikke blive det store problem, da alle tager del i filsystemets funktion. Det betyder at når du gemmer en fil vil din maskine kun gemme en brøkdel lokalt og resten gemmes ud over mange andre maskiner. Dette gør at belastningen spredes og den enkelte maskine ikke bliver en flaskehals.
#10: Dette kan klares ved at kryptere de distribuerede blokke.
#11: Tjek svar til #7.
#12: "laveste fællesnævner der er sætter max. kapaciteten for systemet?"
Dette kan der arbejdes udenom, ved at have flere tilstande for maskinerne i systemet. Man kunne fx. forestille sig at en person kommer med en bærbar og kobler sig på systemet for at hente noget data, men det ville ikke være hensigtsmæssigt at gemme blokke på den computer, så istedet kan maskinen sættes i en ren læse-tilstand. Computere hvis disk er fyldt kan dermed koble sig af skrive delen med stadig have data liggende.
#13: Jeps, begrebet hedder caching :)
Håber det gav lidt mere indsigt i projektet.
#1: "Eller mener de måske at det er ialt imellem alle clienter ?
For så er 160 Mbit/s å¨en 100 Mbit/s backbone også rimeligt godt klaret."
Test netværket bestod af 96 computere, 4 stk. 24 ports 10 Mbit switche koblet op til en 100 Mbit backbone.
Setup: http://www.cs.auc.dk/~lau/heurika/test-network.png
Testresultatet stammer så fra det samlede hastighed i hele systemet. Grunden til at vi kunne nå over de 100 Mbit som backbonen tillader er at computerne også kan snakke internt i hver switch.
#2: Man kan specificere replikationskonstanten som systemet bruger (altså det antal kopier der er af hver block/fil i systemet).
#4: Det du nævner med strømforbruget af computere i en virksomhed er ikke helt rigtigt. I mange virksomheder slukkes computerne ikke om natten, da der så fx. køres sikkerhedsopdateringer ol.
Der er selvfølgelig scenarier som netværket ikke er så god til at håndtere. Eksemplet du kommer med lyder noget kundtigt, da man sjælden vil skrive store data mængder med korte intervaller (fx. ved videoredigering bruges ofte specielle A/V diske).
#6: Det er faktisk lige omvendt. Det er selvfølgelig noget overhead i et P2P system, da computerne skal snakke sammen, men ellers kan man opnå meget højere udnyttelse af netværket data alle maskiner er servere og derfor tilbyder filer. Det der er stor overhead i er når det skrives, da det skal replikeres i et antal eksemplarer, men det er nødvendigt for at opnå den høje tilgængelighed af filerne.
#7: Det skulle ikke blive det store problem, da alle tager del i filsystemets funktion. Det betyder at når du gemmer en fil vil din maskine kun gemme en brøkdel lokalt og resten gemmes ud over mange andre maskiner. Dette gør at belastningen spredes og den enkelte maskine ikke bliver en flaskehals.
#10: Dette kan klares ved at kryptere de distribuerede blokke.
#11: Tjek svar til #7.
#12: "laveste fællesnævner der er sætter max. kapaciteten for systemet?"
Dette kan der arbejdes udenom, ved at have flere tilstande for maskinerne i systemet. Man kunne fx. forestille sig at en person kommer med en bærbar og kobler sig på systemet for at hente noget data, men det ville ikke være hensigtsmæssigt at gemme blokke på den computer, så istedet kan maskinen sættes i en ren læse-tilstand. Computere hvis disk er fyldt kan dermed koble sig af skrive delen med stadig have data liggende.
#13: Jeps, begrebet hedder caching :)
Håber det gav lidt mere indsigt i projektet.
Nightreaver: herlig post. thumbs up. For mig virker det meget som om at folk roder de forskellige lag sammen der er inde i billedet når de snakker om sikkerhed. Der er intet der forhindrer de flittige Aalborgensere i at implementere et krypteringslag.
Den replikationskonstant som Nightreaver nævner, kunne tænkes at gøres dynamisk afhængigt af filens popularitet (eller del af filen, for den sags skyld).
På den måde kunne man sikre størst availability af de mest nødvendige ting og måske kun et par duplikater af en sjældent polled ressource. Ikke alene vil de mest brugte ting være mest tilgængelig og dermed nemmest at sikre en full-duplex switched sti til, men også være mere gjort mere resistent overfor udfald.
Den replikationskonstant som Nightreaver nævner, kunne tænkes at gøres dynamisk afhængigt af filens popularitet (eller del af filen, for den sags skyld).
På den måde kunne man sikre størst availability af de mest nødvendige ting og måske kun et par duplikater af en sjældent polled ressource. Ikke alene vil de mest brugte ting være mest tilgængelig og dermed nemmest at sikre en full-duplex switched sti til, men også være mere gjort mere resistent overfor udfald.
Yeps, helt rigtigt. Det vil også give en øget hastighed på de filer der bruges meget, da man ville kunne hente den fra flere computere.
Forresten, så er jeg en af de 5 "flittige Aalborgensere", hvis nogen skulle være i tvivl :)
Forresten, så er jeg en af de 5 "flittige Aalborgensere", hvis nogen skulle være i tvivl :)
#18
"Det er faktisk lige omvendt. Det er selvfølgelig noget overhead i et P2P system, da computerne skal snakke sammen, men ellers kan man opnå meget højere udnyttelse af netværket data alle maskiner er servere og derfor tilbyder filer. Det der er stor overhead i er når det skrives, da det skal replikeres i et antal eksemplarer, men det er nødvendigt for at opnå den høje tilgængelighed af filerne."
Det jeg tænkte på er at 'ægte' p2p netværk, hvor der ikke er en server indblandet på nogen måde, ofte bliver ineffektive da det kan være svært at finde en indgang til netværket. Der er centralisering somregel mere effektivt.
Og mht. resten, så kommer det jo an på hvordan man definerer effektivitet, korrekt den type system vil stille flere ressourcer til rådighed, men om den vil skabe større hastigheder i forhold til den båndbredde alle peers har, vil jeg meget tvivle på.
"Det er faktisk lige omvendt. Det er selvfølgelig noget overhead i et P2P system, da computerne skal snakke sammen, men ellers kan man opnå meget højere udnyttelse af netværket data alle maskiner er servere og derfor tilbyder filer. Det der er stor overhead i er når det skrives, da det skal replikeres i et antal eksemplarer, men det er nødvendigt for at opnå den høje tilgængelighed af filerne."
Det jeg tænkte på er at 'ægte' p2p netværk, hvor der ikke er en server indblandet på nogen måde, ofte bliver ineffektive da det kan være svært at finde en indgang til netværket. Der er centralisering somregel mere effektivt.
Og mht. resten, så kommer det jo an på hvordan man definerer effektivitet, korrekt den type system vil stille flere ressourcer til rådighed, men om den vil skabe større hastigheder i forhold til den båndbredde alle peers har, vil jeg meget tvivle på.
Hej,
#21:
"Det jeg tænkte på er at 'ægte' p2p netværk, hvor der ikke er en server indblandet på nogen måde, ofte bliver ineffektive da det kan være svært at finde en indgang til netværket. Der er centralisering somregel mere effektivt."
I et lokalt lan-netwærk (med måske 50-500 klienter), som dette system er designet til, anser vi det ikke til at være et større problem at få klienterne til at finde hinanden. Selvom der i det nuværende design ikke optræder en multicast protokol til at finde andre klienter, er det bestemt ikke tanken at have en central server til den slags. Systemet er og bliver fuldstændigt decentralt og vel dermed et 'ægte' p2p netværk om du vil :)
#21:
"Det jeg tænkte på er at 'ægte' p2p netværk, hvor der ikke er en server indblandet på nogen måde, ofte bliver ineffektive da det kan være svært at finde en indgang til netværket. Der er centralisering somregel mere effektivt."
I et lokalt lan-netwærk (med måske 50-500 klienter), som dette system er designet til, anser vi det ikke til at være et større problem at få klienterne til at finde hinanden. Selvom der i det nuværende design ikke optræder en multicast protokol til at finde andre klienter, er det bestemt ikke tanken at have en central server til den slags. Systemet er og bliver fuldstændigt decentralt og vel dermed et 'ægte' p2p netværk om du vil :)
Btw. tak for alle kommentarende, det er rart at så mange giver sin mening til kende om emnet. (Det skulle have stået øverst i nr. 22)
I øjeblikket kræver systemet en IP på en vilkårlig maskine i netværket for at melde sin "ankomst". Men efter det er gjort bruges en hashfunktion og en specielt netværkstopologi til at holde styr på lokaliteten af blokkene. Som jkjonline også forklarer er systemet designet til en virksomhed og derfor et LAN, hvilket gør at vi kan gør os nogle antagelser om det fysiske netværk.
Jeg må da lige pointere at det langt fra er nogen ny idé. Metoden er set tidligere, jeg har endda været i besiddelse af et whitepaper fra et amerikansk universitet som beskriver et system som ligner det omtalte meget til forveksling. Det er derfor også svært at vide om de studerende som er omtalt i nyheden virkelig selv har fundet på ideen.
#22,23,24
En anden ting, der er rent definationsteknisk, er at jeg har svært ved at se hvorfor det bliver kaldt et filsystem. Som jeg ser det er filsystemet det laveste niveau, f.ex. reiserfs, fat osv.. Men det i vil er at bruge kontormaskiner til at opbevare filerne, og dermed vil i bruge den overskydende plads. Jeg går ikke udfra at i vil bruge jeres eget filsystem på det niveau, da det jo nok bliver noget bøvl at integrere i systemerne.
Så i det øjeblik i definerer jeres software som et filsystem, så vil en database vel også falde ind under 'et filsystem'. Okay, i reiserfs tilfælde kan det vel næsten komme ud på det samme, men alligevel.
En anden ting, der er rent definationsteknisk, er at jeg har svært ved at se hvorfor det bliver kaldt et filsystem. Som jeg ser det er filsystemet det laveste niveau, f.ex. reiserfs, fat osv.. Men det i vil er at bruge kontormaskiner til at opbevare filerne, og dermed vil i bruge den overskydende plads. Jeg går ikke udfra at i vil bruge jeres eget filsystem på det niveau, da det jo nok bliver noget bøvl at integrere i systemerne.
Så i det øjeblik i definerer jeres software som et filsystem, så vil en database vel også falde ind under 'et filsystem'. Okay, i reiserfs tilfælde kan det vel næsten komme ud på det samme, men alligevel.
#18
I mange virksomheder slukkes computerne ikke om natten, da der så fx. køres sikkerhedsopdateringer ol.
Det er lang fra rigtigt... Jeg arbejder som systemkonsult i en af danmarks største konsulenthuse, og jeg har kun set en enkelt kunde der tog backup af sine arbejdspladser hver nat...
Man skal ikke tage backup af sine klienter... Man skal sikre at alle vitale data ligger på centrale servere, og sikre at klienterne kan installeres hurtigt og smærtefrit hvis noget går galt..
Strømforbruget alene vil kunne tjene en monster server ind for selv små kunder med 50 brugere...
Desuden er antallet af bærbar pc'er og tynde klienter for kraftigt opadgående... Og de skal vel ikke bruges ???
Ideen er sjov, men jeg tror kun det er meget få virksomheder der kan udnytte det i praksis...
/Ronni
I mange virksomheder slukkes computerne ikke om natten, da der så fx. køres sikkerhedsopdateringer ol.
Det er lang fra rigtigt... Jeg arbejder som systemkonsult i en af danmarks største konsulenthuse, og jeg har kun set en enkelt kunde der tog backup af sine arbejdspladser hver nat...
Man skal ikke tage backup af sine klienter... Man skal sikre at alle vitale data ligger på centrale servere, og sikre at klienterne kan installeres hurtigt og smærtefrit hvis noget går galt..
Strømforbruget alene vil kunne tjene en monster server ind for selv små kunder med 50 brugere...
Desuden er antallet af bærbar pc'er og tynde klienter for kraftigt opadgående... Og de skal vel ikke bruges ???
Ideen er sjov, men jeg tror kun det er meget få virksomheder der kan udnytte det i praksis...
/Ronni
Forstår ikke lige ideen med den her "forskning". At lagre og dele data på et netværk (via en/flere server'ere) er ikke særligt dyrt at håndtere.
Vist bare et nyt eksempel på at forskning kan køre lidt af sporet.
Vist bare et nyt eksempel på at forskning kan køre lidt af sporet.
#26: Vores sytem varetager alle de opgraver du forbinder med et filsystem. Der er altså det standard postix UNIX interface, med open(), close(), seek(), read(), write() osv. Vores _filsystem_ består så at flere dele, hvor den ene er filsystemsinterfacet (de nævnte funktioner) som står for at holde styr på hvor mange blokke der er i en fil, dele filen op i blokke, varetage katalogopslag og lignende opgaver. Dette er altsammen meget standard filsystems operationer.
Dertil kommer så det rigtig spændende nemlig den del af systemet som tager sig af distributionen af de blokke den modtager fra filsystemsmodulet. Det er her alt magien sker.
Den distribuerede hash tabel (som den hedder) holder styr på; dels de blokke som er gemt lokalt på maskinen og dels en routingtabel over kendte computere i systemet. Blokkene og maskinerne er organiserede i et hashrum (hash space, for at ingen er i tvivl), hvor alle computerer og blokke har hver sin unik nøgle (hashværdi). Tricket er så at navigere rundt i det rum på en fonuftig måde så man optimerer opslag, omdøbninger af filer, symobliske links, mapper osv.
Hvis du stigende intresse, bør du læse rapporten, der ligger på:
http://www.cs.auc.dk/~jasper/dat3/
Dertil kommer så det rigtig spændende nemlig den del af systemet som tager sig af distributionen af de blokke den modtager fra filsystemsmodulet. Det er her alt magien sker.
Den distribuerede hash tabel (som den hedder) holder styr på; dels de blokke som er gemt lokalt på maskinen og dels en routingtabel over kendte computere i systemet. Blokkene og maskinerne er organiserede i et hashrum (hash space, for at ingen er i tvivl), hvor alle computerer og blokke har hver sin unik nøgle (hashværdi). Tricket er så at navigere rundt i det rum på en fonuftig måde så man optimerer opslag, omdøbninger af filer, symobliske links, mapper osv.
Hvis du stigende intresse, bør du læse rapporten, der ligger på:
http://www.cs.auc.dk/~jasper/dat3/
#29
Jeg synes da der er interessante aspekter ved måden at gå frem på. Men lige for at høre, dvs. i har implementeret et filsystem oven på et filsystem? Det kan hurtigt blive sjovt, har i nogen tal på hvor stort overhead der kommer på de forskellige filsystemer? Kunne forestille mig at højoptimerede filsystemer kunne give nogle dårlige resultater med sådan noget.(du kører 2 forskellige caching systemer oven på hinanden)
Men det lyder da fedt at det er lavet som et abstraktionslag. Dvs. at man i praksis kan integrere filsystemet ind på kerneniveau og læse det ligesom alle andre filsystemer! Må indrømme at nu kan jeg faktisk ligepludselig også se det innovative i det. :) Lyder som noget der er værd at videreudvikle på, held og lykke, håber engang at se et linux kernelpatch til det, kunne da være usigeligt smart at have det som et integreret filsystem.
Jeg synes da der er interessante aspekter ved måden at gå frem på. Men lige for at høre, dvs. i har implementeret et filsystem oven på et filsystem? Det kan hurtigt blive sjovt, har i nogen tal på hvor stort overhead der kommer på de forskellige filsystemer? Kunne forestille mig at højoptimerede filsystemer kunne give nogle dårlige resultater med sådan noget.(du kører 2 forskellige caching systemer oven på hinanden)
Men det lyder da fedt at det er lavet som et abstraktionslag. Dvs. at man i praksis kan integrere filsystemet ind på kerneniveau og læse det ligesom alle andre filsystemer! Må indrømme at nu kan jeg faktisk ligepludselig også se det innovative i det. :) Lyder som noget der er værd at videreudvikle på, held og lykke, håber engang at se et linux kernelpatch til det, kunne da være usigeligt smart at have det som et integreret filsystem.
#30: Ja, det ligger ovenpå det eksisterende filsystem, da vores mål var ikke at holde styr på inodes, cylindere, spor osv. som er forbundet med at skrive på en disk (og dermed et almindeligt filsystem), men i stedet bygge et distriburede filsystem (som vi så har gjort).
Og det er helt rigtigt som du siger; en skønne dag vil systemet måske ligge som kernemodul og hvis Windowsfolkene er rigtig heldige kommer der måske også en Windows driver ;) Det vil tiden vise...
Og det er helt rigtigt som du siger; en skønne dag vil systemet måske ligge som kernemodul og hvis Windowsfolkene er rigtig heldige kommer der måske også en Windows driver ;) Det vil tiden vise...
Som ronnipedersen nævner i #27, så ser jeg også fremtiden modarbejde selv konceptet, idet at bærbare er på kraftig fremmarch. Så sent som i denne uges trykte udgave af comon-avisen kan man læse at væksten af salget af bærbare er meget kraftig pt. Det skyldes hovedsagligt at priserne er presset i bund.
Markedsandelen for stationære kontra bærbare, er således rykket fra at være i forholdet 3:1 til 2:1 i perioden 2001 til 2003. Hvorvidt tallene er lige repræsentative for både det private marked og forretnings markedet, eller om det er sammenlagt, fremgår dog ikke tydligt af artiklen.
Markedsandelen for stationære kontra bærbare, er således rykket fra at være i forholdet 3:1 til 2:1 i perioden 2001 til 2003. Hvorvidt tallene er lige repræsentative for både det private marked og forretnings markedet, eller om det er sammenlagt, fremgår dog ikke tydligt af artiklen.
#27.
Ronni.
Jeg sidder i et firma med ca 1300 ansatte, i vores afdeling alene er vi 35 mennesker hvor maks 4 personer faktisk slukker deres computer hver dag i weekenden når vi måske op på 6 stykker der slukker deres computer.
Så ingen tvivl om at det ville vær noget der ville kunne bruges hos os.
/opy
Ronni.
Jeg sidder i et firma med ca 1300 ansatte, i vores afdeling alene er vi 35 mennesker hvor maks 4 personer faktisk slukker deres computer hver dag i weekenden når vi måske op på 6 stykker der slukker deres computer.
Så ingen tvivl om at det ville vær noget der ville kunne bruges hos os.
/opy
#33
"Som ronnipedersen nævner i #27, så ser jeg også fremtiden modarbejde selv konceptet, idet at bærbare er på kraftig fremmarch."
Tja, måske. Det er ikke min opfattelse og tro at bærbare vil afløse faste klienter, men det må tiden jo mene. Det er ideen at bærbare sagtens kan tilgå systemet uden at være forpligtet til at bære ansvar for blokke. Det er derfor kun et problem med fremtiden hvis den helt afløser faste klienter og det er jeg svært ved at tro. But how knows ;-)
"Som ronnipedersen nævner i #27, så ser jeg også fremtiden modarbejde selv konceptet, idet at bærbare er på kraftig fremmarch."
Tja, måske. Det er ikke min opfattelse og tro at bærbare vil afløse faste klienter, men det må tiden jo mene. Det er ideen at bærbare sagtens kan tilgå systemet uden at være forpligtet til at bære ansvar for blokke. Det er derfor kun et problem med fremtiden hvis den helt afløser faste klienter og det er jeg svært ved at tro. But how knows ;-)
#25 "...jeg har endda været i besiddelse af et whitepaper fra et amerikansk universitet som beskriver et system som ligner det omtalte meget til forveksling. Det er derfor også svært at vide om de studerende som er omtalt i nyheden virkelig selv har fundet på ideen."
Det er især svært at vide når du hverken nævner navnet på det system du omtaler eller smider et link til dit white paper. Hvorvidt dit system ligner meget eller lidt ved jeg derfor ikke, men de systemer vi har fundet frem til adskiller sig på væsentlige punkter. Hovedparten er udviklet til wide-area-network hvor man forsøger at løse helt andre problemstillinger.
Det kunne være fedt hvis du smed et link :)
Det er især svært at vide når du hverken nævner navnet på det system du omtaler eller smider et link til dit white paper. Hvorvidt dit system ligner meget eller lidt ved jeg derfor ikke, men de systemer vi har fundet frem til adskiller sig på væsentlige punkter. Hovedparten er udviklet til wide-area-network hvor man forsøger at løse helt andre problemstillinger.
Det kunne være fedt hvis du smed et link :)
#34
Det er både en stor sikkerhedbrist, og en KÆMPE ekstra udgift.
Hvis jeres IT Chef ikke kan se det, burde han måske finde sig et nyt arbejde...
Hvis max. 89% af jeres 1300 ansatte (1157), ikke slukker deres PC, hver nat (uden god grund), betyder det at I bruger 168 timers strøm pr. uge pr. pc frem for 37 timer. Det er 4,5 gange det nødvendige..
Samlet set er det 1157 PC'er der er tændt 131 timer for meget pr. uge = 151.567 timer pr. uge eller 53.957.852 timer pr. år.
Det koster ca. 0,20.- pr. time i strøm = 10.791.570,4
10 MILIONER KRONER !!!!!
Måske regenestykket ikke 100% rigtigt, men jeg håber at du har fattet min pointe...
/Ronni
Det er både en stor sikkerhedbrist, og en KÆMPE ekstra udgift.
Hvis jeres IT Chef ikke kan se det, burde han måske finde sig et nyt arbejde...
Hvis max. 89% af jeres 1300 ansatte (1157), ikke slukker deres PC, hver nat (uden god grund), betyder det at I bruger 168 timers strøm pr. uge pr. pc frem for 37 timer. Det er 4,5 gange det nødvendige..
Samlet set er det 1157 PC'er der er tændt 131 timer for meget pr. uge = 151.567 timer pr. uge eller 53.957.852 timer pr. år.
Det koster ca. 0,20.- pr. time i strøm = 10.791.570,4
10 MILIONER KRONER !!!!!
Måske regenestykket ikke 100% rigtigt, men jeg håber at du har fattet min pointe...
/Ronni
#37
Jeg vil give Ronni ret. Systemet/konceptet falder jo til jorden når folk slukker deres PC. Så siger andre her i tråden godt nok at der ikke er nogen i deres virksomhed der slukker deres PC når de går hjem, og det er nok også meget rigtigt. Men hvis de blev slukket kunne det fint sparer penge nok til en stor flot filserver. Og nu ligger landt jo også sådan at vi SKAL sparer på strømmen for at hjælpe miljøet og det her system går jo fuldstændig den modsatte vej.
Desuden er der jo også slidet på alle de computere iforhold til slidet på en enkelt filserver som er beregnet til at stå tændt 24/7
Men projektet lyder da vildt spændende og kanon for nogle studerende at arbejde med. Men som mange andre af sådanne ting så hænger det desværre ikke sammen med den virkelige verden.
Jeg vil give Ronni ret. Systemet/konceptet falder jo til jorden når folk slukker deres PC. Så siger andre her i tråden godt nok at der ikke er nogen i deres virksomhed der slukker deres PC når de går hjem, og det er nok også meget rigtigt. Men hvis de blev slukket kunne det fint sparer penge nok til en stor flot filserver. Og nu ligger landt jo også sådan at vi SKAL sparer på strømmen for at hjælpe miljøet og det her system går jo fuldstændig den modsatte vej.
Desuden er der jo også slidet på alle de computere iforhold til slidet på en enkelt filserver som er beregnet til at stå tændt 24/7
Men projektet lyder da vildt spændende og kanon for nogle studerende at arbejde med. Men som mange andre af sådanne ting så hænger det desværre ikke sammen med den virkelige verden.
#39, #37 - El og Strøm :)
10.000.000 kr. lyder som lidt højt sat, men lad det ligge.
Jeg tror man overordnet kan sige der findes to slags virksomheder. Dem der slukker computerne om natten og dem der ikke gør.
Jeg har svært ved at se problemet ved systemet, betragt følgende løsningsmodeller.
Dem der slukker maskinerne:
Løsning: Fil systemet udvides således at en eller flere 'over knuder' kan udvælges således at disse indeholder alle filer. Disse maskiner står tændt døgnet rundt og er single point of failure når ingen andre spande er tændt. Hvad er så pointen ved at have dette filsystem?
-At der ikke er single point of failure når klienterne er tændte.
-At der er bedre udnyttelse af netværksressourcer.
-At overknuderne ikke behøver samme stabilitet og ydeevne som en almindelig filserver og er derfor billigere.
Dem der ikke slukker maskiner:
Ja, der er det jo bare fint.
10.000.000 kr. lyder som lidt højt sat, men lad det ligge.
Jeg tror man overordnet kan sige der findes to slags virksomheder. Dem der slukker computerne om natten og dem der ikke gør.
Jeg har svært ved at se problemet ved systemet, betragt følgende løsningsmodeller.
Dem der slukker maskinerne:
Løsning: Fil systemet udvides således at en eller flere 'over knuder' kan udvælges således at disse indeholder alle filer. Disse maskiner står tændt døgnet rundt og er single point of failure når ingen andre spande er tændt. Hvad er så pointen ved at have dette filsystem?
-At der ikke er single point of failure når klienterne er tændte.
-At der er bedre udnyttelse af netværksressourcer.
-At overknuderne ikke behøver samme stabilitet og ydeevne som en almindelig filserver og er derfor billigere.
Dem der ikke slukker maskiner:
Ja, der er det jo bare fint.
#6
http://freenet.sourceforge.net/
men der er noget kryptering or andre gode ting med, de har bare nogle store problemer for tiden med deres nye routing protokol(læs: det kører af lort til).
http://freenet.sourceforge.net/
men der er noget kryptering or andre gode ting med, de har bare nogle store problemer for tiden med deres nye routing protokol(læs: det kører af lort til).
#40
"Vil det ikke være en unormalt langvarig process? og hvordan så med restore?"
Det er ikke testet, men overordnet er en af styrkerne jo netop hastigheden af læse operationen. Flere klienter kan sende data parallelt, så du får kortere vente tid end hvis du skulle hente fra et centralt sted. Selvfølgelig er du bundet af hastigheden af backbonen, men du kan jo hente parallelt fra afdelinger.
Restore er vidst bare en normal skrive operation, hvor filerne vil blive fordelt på samme måde som hvis de enkelte skrev filerne. Hvor blokkene havner afgøres af en hash på filnummer, oprettelses dato samt bloknummer og det forbliver det samme ved backup. Det bemærkes dog at restore som følge af system nedbrud er meget sjældent ved et p2p system, se evt. kapitel 3:
http://www.cs.auc.dk/~jasper/dat3/heurika-report.p...
Der skal selvfølgelig overvejes forskellige optimeringer i forbindelse med backup, men overordnet er der ingen større teoretiske eller praktiske problemer ved det.
"Vil det ikke være en unormalt langvarig process? og hvordan så med restore?"
Det er ikke testet, men overordnet er en af styrkerne jo netop hastigheden af læse operationen. Flere klienter kan sende data parallelt, så du får kortere vente tid end hvis du skulle hente fra et centralt sted. Selvfølgelig er du bundet af hastigheden af backbonen, men du kan jo hente parallelt fra afdelinger.
Restore er vidst bare en normal skrive operation, hvor filerne vil blive fordelt på samme måde som hvis de enkelte skrev filerne. Hvor blokkene havner afgøres af en hash på filnummer, oprettelses dato samt bloknummer og det forbliver det samme ved backup. Det bemærkes dog at restore som følge af system nedbrud er meget sjældent ved et p2p system, se evt. kapitel 3:
http://www.cs.auc.dk/~jasper/dat3/heurika-report.p...
Der skal selvfølgelig overvejes forskellige optimeringer i forbindelse med backup, men overordnet er der ingen større teoretiske eller praktiske problemer ved det.
#37 - Bare lige for at bidrage lidt til strøm forbrugs aspektet:
Las os nu sige at alle medarbejderne bruger 15 min hverdag på at tænde og slukke computeren (Incl. åbne/lukke alle programmer, logge ind ol.). Den tid ville de ellers bruge på at arbejde hvis deres computer havde været tændt. Lad os så antage at det ca. koster 200 kr i timen at have en person siddene (Det er ikke timeløn, men det det koster virksomheden at have medarbejderen). De 200 kr er meget lavt sat for virksomheder med mange ingenører ol. og måske lidt højt sat hvis der et tale om "almindlige" kontorarbejdere.
Hvis en medarbejder arbejder 5 dage i 45 uger om året taber virksomheden 5*45*200*0.25*1157 ~= 13 Milioner kroner i tabt arbejde.
Las os nu sige at alle medarbejderne bruger 15 min hverdag på at tænde og slukke computeren (Incl. åbne/lukke alle programmer, logge ind ol.). Den tid ville de ellers bruge på at arbejde hvis deres computer havde været tændt. Lad os så antage at det ca. koster 200 kr i timen at have en person siddene (Det er ikke timeløn, men det det koster virksomheden at have medarbejderen). De 200 kr er meget lavt sat for virksomheder med mange ingenører ol. og måske lidt højt sat hvis der et tale om "almindlige" kontorarbejdere.
Hvis en medarbejder arbejder 5 dage i 45 uger om året taber virksomheden 5*45*200*0.25*1157 ~= 13 Milioner kroner i tabt arbejde.
#46: Interessant betragtning - men vil de fleste ikke tænde computeren når de kommer ind på kontoret, og derefter stille deres taske, hænge jakken på knagen, hente en kop kaffe etc. og så logge på? I længden vil det vel højest være 5 minutter pr. medarbejder vi snakker om (og det tæller selvfølgelig også).
Og ved nedlukning er det jo bare at fortælle comp'en den skal slukke og så klarer den selv resten.
For at sætte strømforbruget i perspektiv - så bruger en virksomhed med ca. 50 kontorpladser hvor maskinerne er slukket ca. 800 dkk om dagen på standby strøm alene. Dvs. godt 1/4 million/år - så at sige at man bruger 4 gange den strøm når maskinerne kører er vel ikke at overdrive :)
Og ved nedlukning er det jo bare at fortælle comp'en den skal slukke og så klarer den selv resten.
For at sætte strømforbruget i perspektiv - så bruger en virksomhed med ca. 50 kontorpladser hvor maskinerne er slukket ca. 800 dkk om dagen på standby strøm alene. Dvs. godt 1/4 million/år - så at sige at man bruger 4 gange den strøm når maskinerne kører er vel ikke at overdrive :)
#48: Jeg er udemærket klar over at der er mange usikkerheder i min beregning. Men jeg tvivler også på at der i strømforbrugs beregningen er ting som strømforbruget af en idle computer med slukket skærm.
Udover det åbner jeg typisk en browser, mail, emacs (med 10-15 filer i bufferen), 3-4 pdf filer ++ for at jeg er oppe at køre så for mig er 15 min nok lavt sat.
Udover det åbner jeg typisk en browser, mail, emacs (med 10-15 filer i bufferen), 3-4 pdf filer ++ for at jeg er oppe at køre så for mig er 15 min nok lavt sat.
#alle
Ud over strøm forbruget, er der også mange andre fejl vuderinger (som jeg ser det).
Feks.: (citat)
Dette bevirker at man kan blive fri for at investere i en server med masser af plads.
Nej vel...
Servere er langt mere end fil shares. Hvad med mail, print, ERP, CRM, Client Management, Backup osv.
Selv om man placere filerne på alternative løsniger (feks. NAS), skal disse data stadig administreres af en server (rettighederne til de forskellige filer feks.)
En af disse servere, som firmaet stadig er nød til at købe kan formentligt håndtere filshare sammen med en anden opgave...
Derfor er der INGEN besparelser på administrative opgaver, server hardware, licenser o.lign.
Kun rå disk plads... og det koster som bekendt ikke alverden.
IBM SCSI diske ligger under 50.- pr. GB.
Jeg er meget åben for nye teknologier, og syntes det er totalt fedt at I bruger en masse tid på det... Der skal nok komme noget ud af det, det er helt sikkert !! Jeg tror bare ikke det bliver på den måde det er beskrevet...
Jeg kunne feks. forestille mig at det blev brugt som en slags backup, der kunne arbejdes på, i tilfælde af nedbrud på servere, backbone eller lign.
Lidt som "offline files"... Men som en erstatning for fil servere, tror jeg ikke på...
/Ronni
Ud over strøm forbruget, er der også mange andre fejl vuderinger (som jeg ser det).
Feks.: (citat)
Dette bevirker at man kan blive fri for at investere i en server med masser af plads.
Nej vel...
Servere er langt mere end fil shares. Hvad med mail, print, ERP, CRM, Client Management, Backup osv.
Selv om man placere filerne på alternative løsniger (feks. NAS), skal disse data stadig administreres af en server (rettighederne til de forskellige filer feks.)
En af disse servere, som firmaet stadig er nød til at købe kan formentligt håndtere filshare sammen med en anden opgave...
Derfor er der INGEN besparelser på administrative opgaver, server hardware, licenser o.lign.
Kun rå disk plads... og det koster som bekendt ikke alverden.
IBM SCSI diske ligger under 50.- pr. GB.
Jeg er meget åben for nye teknologier, og syntes det er totalt fedt at I bruger en masse tid på det... Der skal nok komme noget ud af det, det er helt sikkert !! Jeg tror bare ikke det bliver på den måde det er beskrevet...
Jeg kunne feks. forestille mig at det blev brugt som en slags backup, der kunne arbejdes på, i tilfælde af nedbrud på servere, backbone eller lign.
Lidt som "offline files"... Men som en erstatning for fil servere, tror jeg ikke på...
/Ronni
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund