Venti
Venti är ett nätverkslagringssystem som permanent lagrar datablock. En 160-bitars SHA-1- hash av data (kallad score av Venti) fungerar som adressen till datan. Detta upprätthåller en skriv-en gång- policy eftersom inget annat datablock kan hittas med samma adress: adresserna för flera skrivningar av samma data är identiska, så dubblettdata är lätt att identifiera och datablocket lagras bara en gång. Datablock kan inte tas bort, vilket gör den idealisk för permanent lagring eller säkerhetskopiering. Venti används vanligtvis med Fossil för att förse ett filsystem med permanenta ögonblicksbilder.
Historia
Venti designades och implementerades av Sean Quinlan och Sean Dorward på Bell Labs . Det dök upp i Plan 9- distributionen 2002. Utvecklingen har fortsatt av Russ Cox som har omimplementerat större delen av servern, skrivit ett bibliotek för att skapa datastrukturer (filer, kataloger och metadata) för att lagra i Venti och implementerat optimeringar. Venti är tillgänglig både i Plan 9-distributionen och för många UNIX-liknande operativsystem som en del av Plan 9 från User Space . Venti ingår som en del av Inferno med tillhörande moduler för åtkomst. Det finns en Go- uppsättning program för att bygga dina egna Venti-servrar. Inkluderat är exempel som använder olika typer av backend-lagring.
Detaljer
Venti är en användarrymddemon . Klienter ansluter till Venti över TCP och kommunicerar med ett enkelt RPC -protokoll. De viktigaste meddelandena i protokollet listas nedan. Observera att det inte finns något meddelande om att radera en adress eller ändra data på en given adress.
- läs(poäng, typ) , returnerar data som identifierats av poäng och typ
- write(data, type) , lagrar data på adressen beräknad av SHA-1-hash- data , kombinerat med typ .
Datablocket som lagras av Venti måste vara längre än 512 byte och mindre än 56 kilobyte. Så om en Venti-användare/klient vill lagra större datablock måste den skapa en datastruktur (som kan lagras i Venti). Till exempel använder Fossil hashträd för att lagra stora filer. Venti själv berör inte innehållet i ett datablock; den lagrar dock typen av ett datablock.
Utformningen av Venti har följande konsekvenser:
- Eftersom skrivningar är permanenta är filsystemet endast tillägg (vilket möjliggör en enkel implementering med lägre chans att dataförstörande buggar); ingen filsystemfragmentering inträffar .
- Klienter kan verifiera serverns korrekthet: poängen för den returnerade informationen bör vara densamma som den begärda adressen. Eftersom SHA-1 är en kryptografiskt säker hash, är det beräkningsmässigt omöjligt att tillverka data.
- Data kan inte skrivas över. Om en adress redan finns finns data redan närvarande.
- Det finns lite behov av användarautentisering: Data kan inte raderas och kan endast läsas om poängen är känd. Det enda potentiella problemet är att en användare fyller på diskarna.
- Data kan komprimeras utan att göra diskstrukturen komplicerad.
Datablocken lagras på hårddiskar . Diskarna som utgör det tillgängliga lagringsutrymmet, vanligtvis en RAID , kallas dataloggen . Denna datalogg är uppdelad i mindre bitar som kallas arenor , som är dimensionerade så att de kan skrivas till andra medier som CD / DVD eller magnetband . En annan uppsättning hårddiskar används för indexet, som mappar poäng till adresser i dataloggen. Datastrukturen som används för indexet är en hashtabell med hinkar med fast storlek. Venti förlitar sig på att poängen fördelas slumpmässigt så att hinkar inte fylls. Eftersom varje uppslagning kostar en disksökningstid , består ett index vanligtvis av flera hårddiskar med låg åtkomsttid .
Användande
Venti-servern kan användas av klienter på flera sätt. Operativsystemet Plan 9 använder Venti för dagliga arkivbilder av filsystemet. Dessa kopior av huvudfilsystemet kan monteras som ett filträd med fullständiga kopior organiserade efter datum. Verktygsprogrammen 'vac' och 'unvac' kan användas för att lagra och hämta data från en Venti-server i form av enskilda filer eller som en katalog och dess innehåll. "Vacfs" tillåter bläddring av data som är associerade med en vac-poäng utan fullständig hämtning av all fjärrlagrad data. Data och indexpoäng kan dupliceras mellan Venti-servrar med "rdarena" och "wrarena". Plan 9 från Bell Labs , Plan 9 från User Space, Inferno och alla andra klienter som implementerar Venti-protokollet kan alla användas omväxlande för att lagra och hämta data.
Hashkollisioner
En grundläggande princip för informationsteori är duvhålsprincipen , som säger att om mängd A innehåller fler värden än mängd B, så kommer det för alla funktioner som mappar A till B att finnas medlemmar av B som är associerade med mer än en medlem av mängd A I fallet med Venti är uppsättningen av möjliga SHA-1-hashar uppenbarligen mindre än uppsättningen av alla möjliga block som skulle kunna lagras i filsystemet, och därför är en hashkollision möjlig .
Risken för oavsiktlig hashkollision i en 160-bitars hash är mycket liten, även för exabyte data. Historiskt har dock många hashfunktioner blivit allt mer sårbara för skadliga hashkollisioner på grund av både kryptografiska och beräkningsmässiga framsteg. Venti tar inte upp frågan om hashkollisioner; från och med den här tiden, [ när? ] är det fortfarande beräkningsmässigt omöjligt att hitta kollisioner i SHA-1, men det kan bli nödvändigt för Venti att byta till en annan hashfunktion någon gång i framtiden. Den 23 februari 2017 tillkännagav Google SHAttered- attacken, där de genererade två olika PDF-filer med samma SHA-1-hash i ungefär 2 63.1 SHA-1-utvärderingar.
Se även
- Fossil - snapshot-filsystem som använder Venti för permanent lagring
- Plan 9 från User Space
externa länkar
- Venti: ett nytt tillvägagångssätt för arkivlagring, papper som beskriver Venti.
- Ny Venti manualsida (översikt) , avsnitt 7 Venti manualsida inklusive allmän beskrivning och lagringsformat.
- Ny Venti manualsida (server) , avsnitt 8 Venti server manualsida.
- Ny Venti manualsida (verktyg) , avsnitt 1 Venti utilities manualsida.
- Go-kod för implementering av klienter och servrar .
- Venti-modul i Limbo för Inferno , vänligt väckt till liv tack vare Google Summer of Code.