Btrfs | |
Utvikler | Oracle Corporation (opprinnelig) |
---|---|
engelsk navn | Btrfs |
Introduksjon |
Stabil: Linux-kjernen 3.10, 29. juli 2013 ustabil: Linux-kjernen 2.6.29, mars 2009 ( Linux ) |
Struktur | |
Innhold i kataloger | Tre B |
Filallokering | utstrekning |
Begrensninger | |
Maksimal filstørrelse | 16 Eio |
Maksimalt antall filer | 2 64 |
Maksimal filnavnstørrelse | 255 byte |
Maksimal volumstørrelse | 16 Eio |
Tegn tillatt i filnavn | Alle unntatt NUL ('\ 0') og '/' |
Funksjoner | |
Registrerte datoer | modifikasjon (mtime), modifikasjon av attributter (ctime), tilgang (atime) |
Attributter | POSIX , utvidede attributter |
Tillatelser | POSIX, ACL |
Integrert komprimering | Ja ( zlib , LZO og (siden kjernen 4.14) Zstd ) |
Integrert kryptering | Planlagt |
Btrfs ( B-tree filsystem , uttalt ButterFS) er et filsystem fra 2010-tallet basert på Copy-On-Write (copy-on-write på fransk) under GNU GPL , utviklet av Oracle , Red Hat , Fujitsu , Intel , SUSE , STRATO AG (in) og andre. I 2012, da det ennå ikke ble ansett for å være ganske stabilt, ble det gitt en intens utvikling og testing av samfunnet for å gjøre Btrfs til etterfølgeren til ext4 og ext3 , de vanlige filsystemene for distribusjoner. OpenSuse 13.2 tilbyr standard Btrfs for rotpartisjonen fra lanseringen for å sikre sikkerhet og gir valget mellom ext4 og XFS (raskere) for / home.
Btrfs gir følgende funksjoner som ikke finnes i andre filsystemer:
Disse egenskapene er viktige for Linux-systemer, både servere og klientarbeidsstasjoner, da lagringsstørrelser og konfigurasjoner har en tendens til å øke og bli mer komplekse.
Spesielt øyeblikksbildeteknikken sørger for at du kan lage en jevn sikkerhetskopi av systemfiler slik de var på øyeblikkets øyeblikk, selv om sikkerhetskopien tar flere timer og mange filer endres i mellom.
Btrfs-datastrukturen (copy-on-write med Tree B ) er blitt foreslått av en forsker for IBM , Ohad Rodeh , på en konferanse USENIX i 2007. Chris Mason, tidligere ingeniør i SUSE , Oracle begynte i slutten av 2007 og begynner arbeidet med design av Btrfs basert på datastrukturen til B Tree . Muligheten for å sikkerhetskopiere servere uten å avbryte driften er faktisk veldig etterspurt.
Red Hat har fjernet støtte for Btrfs siden RHEL versjon 7.4 , utgitt 1. august 2017. CentOS 8.0 Linux- distribusjonen har ikke lenger noen pakker i sine repositorier for å støtte Btrfs-filsystemer.
Btrfs, som Ext4 , er basert på forestillingen om omfang . Dette er et sammenhengende område (opptil flere hundre MB, i motsetning til klynger på noen få KB eldre) reservert hver gang en fil lagres på harddisken . Når du skriver til slutten av filen (legger til) eller omskriver den helt, går de nye dataene ofte direkte i eksisterende grad i stedet for til et annet område på harddisken. Denne bruken av omfanget reduserer fragmentering , og øker derfor ytelsen på en konvensjonell harddisk (men gir ikke noen gevinst på en SSD ). Denne tidseffektiviteten koster kostnadene for større okkupasjon av diskplass, hvis kostnad er redusert med flere størrelsesordener. Btrfs lagrer også data for svært små filer direkte i katalogfilen , ikke i et eget omfang.
Btrfs opprettholder en forestilling om "undervolumer" som et eget tre (inkludert rot ) av kataloger og filer, og tillater forskjellige trær samtidig, noe som gjør dem mer uavhengige av hovedsystemet. Dataene blir dermed bedre skilt, og forskjellige kvoter kan pålegges av delvolumer. Den største fordelen er muligheten for øyeblikksbilder (også kalt øyeblikksbilder ). Et øyeblikksbilde lar deg "ta et øyeblikksbilde" på et gitt tidspunkt i et filsystem for å lagre det i den konsistente tilstanden mens du fortsetter å jobbe. Dette øyeblikksbildet er et undervolum som kan redigeres etter hvert. Denne skrivemodifiseringen, som er mulig under en sikkerhetskopi (fra en tidligere tilstand), gir høy tilgjengelighet av elektroniske databaser.
For å utnytte disse undervolumene og øyeblikksbildene bruker Btrfs den klassiske " copy-on-write " -teknikken . Hvis data skal skrives til en minneblokk, kopieres minneblokken til et annet sted i filsystemet for ikke å endre originalen, og de nye dataene blir deretter lagret i kopien. Deretter endres metadataene som peker mot blokken automatisk for å ta hensyn til de nye dataene. Denne transaksjonsmekanismen skiller seg fra loggingen som er tilstede i ext3, som husker akkurat hva som eksisterte før du skrev, og holder den til bekreftet at skrivingen gikk bra. Å ta et øyeblikksbilde av systemet vil gjøre det mulig i tilfelle et problem å gå tilbake til øyeblikksbildet umiddelbart, uten å måtte spille av pågående fil på tidspunktet for feilen. I tillegg til ytelsesproblemer (Btrfs har ikke ytelsen til XFS), åpner dette spørsmål: når skal du ta et øyeblikksbilde for hvilke datamengder? Navnet på "øyeblikksbilde", lånt fra fotograferingsverdenen, er misvisende for så vidt som om den frosne tilstanden virkelig er et øyeblikk, tar operasjonen vanligvis noen få titalls millisekunder, selv om den ikke er relatert til titalls minutter av en sikkerhetskopi. Bruken av øyeblikksbilder for dette formålet er ikke et poeng som er lagt fram av utviklerne.
På den annen side er det viktig for synkronisering , arkivering og sikkerhetskopiering , for å sikre at hele det valgte filsystemet blir synkronisert, arkivert eller sikkerhetskopiert, vil være i en tilstand som er i samsvar med hva det var ved starten av operasjonen, selv om operasjonen ble startet. 'Vi fortsetter å jobbe med den, og sikkerhetskopieringen tar flere timer. Denne muligheten tillater konsekvente sikkerhetskopier, forutsatt at IT-teamet implementerer det.
Btrfs har sine egne databeskyttelsesteknikker: bruk av bakreferanser - dvs. å vite, fra en datablokk, som metadata peker mot blokken) gjør det mulig å identifisere systemkorrupsjon. Hvis en fil hevder å tilhøre et sett med blokker, og disse blokkene hevder å tilhøre en annen fil, indikerer dette at systemets konsistens er endret. Btrfs utfører også kontroller av alle data og metadata som er lagret for å kunne oppdage alle slags hot korrupsjon, reparere noen av dem, og dermed tilby et bedre nivå av pålitelighet.
Det gjør det mulig å endre størrelse på filsystemets størrelse (inkludert å krympe den) samtidig som den opprettholder utmerket beskyttelse av metadata som dupliseres flere steder for sikkerhet. Operasjonen er enkel: btrfs filesystem resize +2g /mntlegg til 2 GiB i filsystemet. Denne funksjonen er ikke ment overflødig med det som gir den logiske volumbehandleren for Linux, men hevder den teknisk komplette.
Å sjekke filsystemet gjennom btrfsck- programmet er feiltolerant og spioneringen er ekstremt rask av design. Bruken av B-trær gjør det mulig å utforske strukturen på platen med en hastighet som i det vesentlige er begrenset av lesehastigheten på platen. Baksiden er et stort minnefotavtrykk siden btrfsck bruker tre ganger mer minne enn e2fsck .
Btrfs respekterer hierarkiet av funksjonelle "lag" i Linux. Selv om den for eksempel tilbyr flere funksjoner, prøver den så mye som mulig å ikke omskrive hele volumadministrasjonssystemet som tilbys som standard av LVM .
Btrfs tillater styring av logiske volumer , det vil si å samle flere lagringsenheter.
Btrfs tillater implementering av flere RAID- funksjoner .
Btrfs tillater komprimering av lagrede data . Den kan aktiveres når du redigerer, mens du velger kompresjonstype blant Zstd , Zlib og LZO .
Andre komprimeringsalgoritmer har blitt eller blir vurdert:
Å sikre sikkerheten og konsistensen av data medfører absolutt en kostnad, som imidlertid må sammenlignes med:
Dette blir tilbakekalt:
Den indre driften av Btrfs gjør det praktisk talt umulig å bestemme mengden ledig plass: kommandoen " df " tilsvarer bare det tilsynelatende rommet, ikke det virkelige rommet som kan være mye større. Tidligere ble denne typen problemer bare oppdaget på Linux med hule (eller " hull ") filer .