Redigerer Btrfs (avsnitt)

===Filsystemtreet===
Brukersynlige datafiler og [[Mappe (filsystem)|kataloger]] befinner seg i ''filsystemtreet''. Der er et filsystemtre per undervolum. Undervolumer kan nøstes, og i slike tilfeller opptrer de som et katalogelement (beskrevet nedenfor) hvis data er en referanse til det nøstede undervolumets filsystemtre.

Innenfor filsystemtreet har hver datafil og katalogobjekt et ''[[inode]]element''. [[Utvidede filattributter]] og tilgangen til [[aksesskontrolliste]]r blir lagret sammen med det separate elementet.

Innenfor hver katalog, opptrer et aksesspunkt til katalogen som et ''katalogelement'', hvor høyre nøkkelverdi er en [[syklisk redundanssjekk|CRC-32C]] [[hashfunksjon]] av deres filnavn. Dens data er en ''lokaliseringsnøkkel'', eller en nøkkel til inodeelementet den peker på. Katalogelementet kan således fungere som en indeks for oppslag i inodene, men er ikke brukt til iterasjon fordi de er sortert som en hashfunksjon som utfører en [[tilfeldig permutasjon]].
[[Fil:Fujitsu-Logo.svg|thumb|Logoen til [[Fujitsu]]. Det [[japan]]ske multinasjonale IT-konsernet Fujitsu Limited ([[japansk|nihongo]]: 富士通株式会社) er blant de som har bidratt til utviklingen av btrfs.]]
Dette betyr at brukerprogrammer som gjentatte ganger åpner filer i en stor katalog således vil generere mange flere disksøk mellom filer som ikke er naboer i treet. Dette medfører en nevneverdig svekkelse i ytelsen til andre filsystemer med hashfunksjonordnede kataloger. Dette gjelder blant annet ReiserFS,<ref>{{cite web|url = http://lkml.indiana.edu/hypermail/linux/kernel/0112.0/2019.html|title = Re: Ext2 directory index: ALS paper and benchmarks|work = ReiserFS developers mailing list|first = Hans|last = Reiser|date = 2001-12-07|accessdate = 2009-08-28}}</ref> ext3 (med Htre-indekser aktivert<ref>{{cite web|url = http://oss.oracle.com/~mason/acp/|first = Chris|last = Mason|title = Acp|work = Oracle personal web page|accessdate = 2011-11-05|archive-date = 2021-05-16|archive-url = https://web.archive.org/web/20210516204043/https://oss.oracle.com/~mason/acp/|url-status = yes}}</ref>) og ext4, som alle har navn som er krytptiserte ved hjelp av [[Tiny Encryption Algorithm]]. For å unngå dette, må hver katalog aksesseres av et katalogindekselement, der de høyre bitene av elementets nøkkelverdi er satt til en katalogteller som inkrementeres for hver ny katalogtilgang. Gjentagelser av disse indekselementene returnerer således katalogaksesser i omtrent samme rekkefølge som de er lagret på disken.

I tillegg til inode-elementer, har filer og kataloger også et referanseelement hvor nøkkelverdien i de høyre bitene er satt til objektid til deres foreldrekatalog. Datadelen av referanseelementet er filnavnet som inoden er kjent under i denne katalogen. Dette gjør det mulig å traversere oppover gjennom kataloghierarkiet og sørger for en måte til å veilede inodene tilbake til veiene i treet.

Filer med [[fast kobling|faste koblinger]] i flere kataloger har flere referanseelementer, et for hver foreldrekatalog. Filer med ''flere'' faste koblinger i samme katalog pakker alle koblingens filnavn inn i det samme referanse-element. Der var en konstruksjonsfeil som begrenset antallet faste koblinger i samme katalog til det som var mulig å pakke inn i en enkelt treblokk (som standard er blokkstørrelsen 4 Kb, filnavn har en gjennomsnittlig lengde på 8 bytes og hodet til filnavn er gjennomsnittlig 4 bytes. Dette gir mindre enn 350.). Applikasjoner som gjorde mye bruk av flere faste koblinger til samme katalog, slik som [[Git]], [[Gnus]], [[GMame]] og [[BackupPC]], viste seg senere å krasje etter at de hadde nådd denne grensen.<ref name="hard_link_limit">{{cite web|title=Hard Link Limitation |date=8. august 2010 |accessdate=2011-11-14 |work=kerneltrap.org |url=http://kerneltrap.org/mailarchive/linux-btrfs/2010/8/2/6885208/thread |url-status=dead |archiveurl=https://web.archive.org/web/20120401234546/http://kerneltrap.org/mailarchive/linux-btrfs/2010/8/2/6885208/thread |archivedate=2012-04-01 }}</ref> Denne grensen ble til slutt fjernet<ref>{{citation |title=btrfs: extended inode refs |first=Mark |last=Fasheh |date=2012-10-09 |accessdate=2012-11-07 |url=https://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298 |archiveurl=https://archive.today/20130415062145/http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298# |url-status=dead }}</ref> (en forandring som ble integrert i versjon 3.7 av Linuxkjernen<ref>{{citation |title=Pull btrfs update from Chris Mason |first=Linus |last=Torvalds |date=2012-10-10 |accessdate=2012-11-07 |url=https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5 |work=git.kernel.org |archiveurl=https://archive.today/20130415043758/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5# |url-status=dead }}</ref>) ved å introdusere ''utvidede referanseelementer'' som kunne holde rede på faste koblinger.

====«Extents»====
[[Fil:Red Hat Tower-2013-10-29.jpeg|thumb|Raleigh's Red Hat Tower. Det amerikanske programvareselskapet [[Red Hat]] har hatt en sentral rolle i utviklingen av btrfs.{{byline|Foto:Mark Turner|29. oktober 2013}}]]
Fildata holdes utenfor treet i ''[[extent]]s'', som stadig kjører på diskblokker. Størrelsen på en extent-blokk er 4 Kb i størrelse som standard, har ikke hoder og inneholder bare fildata (som kan være komprimert). I komprimerte extents, er individuelle blokker ikke komprimert separat; i stedet omfatter kompresjonen av strømmen den enkelte extent i sin helhet.

Filer har ''utvidede dataelementer'' som holder rede på de extents som holder på deres innhold. Den høyre delen av elementets nøkkelverdi er det innledende byte offset til denne extent. Dette gjør det mulig å foreta effektive søk i store filer med mange extents, fordi den korrekte extent for enhver gitt filoffset kan beregnes med bare et enkelt oppslag i treet.

Snapshots og klonede filer deler extents. Når en liten del av en større slik extent blir overskrevet, kan det resulterende copy-on-write skape tre nye extents: En liten en som inneholder de overskrevne data, og to større som har umodifiserte data på hver side av overskrivingen. For å unngå å måtte skrive umodifiserte data på nytt, kan copy-on-write i stedet skape ''bookend'' extents, eller extents som kort og godt er deler av eksisterende extents. Extent dataelementer tillater således å inkludere en offset til den extent som de sporer; elementer for ''bookends'' er de som har offset som ikke er lik null.<ref name="btrfs-wiki-1" />

Hvis datafilen er liten nok til å passe innenfor en trenode, blir den i stedet dyttet inn i treet og lagret på innsiden av dataelementets extent. Hver trenode er lagret i sin egen treblokk &ndash; en enkelt ukomprimert blokk med et hode. Treblokken blir betraktet som en frittstående enkeltblokk-extent.