Denna artikel är avsedd att vara en diskussion på mycket hög nivå om Linux filsystemkoncept. Den är inte avsedd att vara en beskrivning på låg nivå av hur en viss filsystemtyp, t.ex. EXT4, fungerar, och den är inte heller avsedd att vara en handledning i filsystemkommandon.
Varje allmännyttig dator behöver lagra data av olika slag på en hårddisk (HDD) eller någon motsvarighet, t.ex. ett USB-minnesstick. Det finns ett par skäl till detta. För det första förlorar RAM-minnet sitt innehåll när datorn stängs av. Det finns icke-flyktiga typer av RAM som kan behålla de data som lagrats där efter att strömmen har tagits bort (t.ex. flash-RAM som används i USB-minneskort och solid state-enheter), men flash-RAM är mycket dyrare än standardiserade, flyktiga RAM som DDR3 och andra, liknande typer.
Den andra anledningen till att data måste lagras på hårddiskar är att även standard-RAM fortfarande är dyrare än diskutrymme. Kostnaderna för både RAM och diskutrymme har sjunkit snabbt, men RAM ligger fortfarande i topp när det gäller kostnaden per byte. En snabb beräkning av kostnaden per byte, baserad på kostnader för 16 GB RAM jämfört med en hårddisk på 2 TB, visar att RAM är ungefär 71 gånger dyrare per enhet än hårddisken. En typisk kostnad för RAM-minne är cirka 0,0000000043743750 dollar per byte i dag.
För en snabb historisk notering för att sätta dagens RAM-kostnader i perspektiv, var en typ av minne i datorernas tidigaste dagar baserad på prickar på en CRT-skärm. Detta var mycket dyrt och kostade ungefär 1,00 dollar per bit!
Definitioner
Du kan höra folk tala om filsystem på ett antal olika och förvirrande sätt. Själva ordet kan ha flera betydelser, och du kan behöva urskilja den rätta betydelsen från sammanhanget i en diskussion eller ett dokument.
Jag kommer att försöka definiera de olika betydelserna av ordet ”filsystem” baserat på hur jag har observerat hur det används under olika omständigheter. Observera att även om jag försöker följa de ”officiella” standardbetydelserna är min avsikt att definiera begreppet utifrån dess olika användningsområden. Dessa betydelser kommer att undersökas närmare i följande avsnitt av den här artikeln.
- Hela Linux katalogstruktur med början i den översta (/) rotkatalogen.
- En specifik typ av datalagringsformat, t.ex. EXT3, EXT4, BTRFS, XFS, och så vidare. Linux stöder nästan 100 typer av filsystem, inklusive några mycket gamla och några av de nyaste. Var och en av dessa filsystemtyper använder sina egna metadatastrukturer för att definiera hur data lagras och nås.
- En partition eller logisk volym som är formaterad med en viss typ av filsystem och som kan monteras på en angiven monteringspunkt i ett Linux-filsystem.
Grundläggande filsystemfunktioner
Disklagring är en nödvändighet som för med sig en del intressanta och oundvikliga detaljer. Självklart är ett filsystem utformat för att tillhandahålla utrymme för icke-flyktig lagring av data; det är dess yttersta funktion. Det finns dock många andra viktiga funktioner som följer av detta krav.
Alla filsystem måste tillhandahålla ett namnutrymme – det vill säga en metod för namngivning och organisering. Detta definierar hur en fil kan namnges, särskilt längden på ett filnamn och den delmängd tecken som kan användas för filnamn av den totala mängden tillgängliga tecken. Den definierar också den logiska strukturen för data på en disk, t.ex. användningen av kataloger för att organisera filer i stället för att bara klumpa ihop dem alla till ett enda stort konglomerat av filer.
När namnrymden väl har definierats är en metadatastruktur nödvändig för att tillhandahålla den logiska grunden för den namnrymden. Detta omfattar de datastrukturer som krävs för att stödja en hierarkisk katalogstruktur; strukturer för att avgöra vilka block av utrymme på disken som används och vilka som är tillgängliga; strukturer som gör det möjligt att upprätthålla filernas och katalogernas namn; information om filerna, t.ex. deras storlek och tidpunkter för när de skapades, ändrades eller senast åtkoms; och platsen eller platserna för de data som hör till filen på disken. Andra metadata används för att lagra information på hög nivå om diskens underavdelningar, t.ex. logiska volymer och partitioner. Denna metadata på högre nivå och de strukturer som den representerar innehåller information som beskriver det filsystem som är lagrat på enheten eller partitionen, men är separat och oberoende av filsystemets metadata.
Filsystem kräver också ett gränssnitt för tillämpningsprogrammering (API) som ger tillgång till systemfunktionsanrop som manipulerar filsystemobjekt som filer och kataloger. API:er tillhandahåller uppgifter som att skapa, flytta och ta bort filer. Det tillhandahåller också algoritmer som bestämmer saker som var en fil placeras i ett filsystem. Sådana algoritmer kan ta hänsyn till mål som snabbhet eller minimering av diskfragmentering.
Moderna filsystem tillhandahåller också en säkerhetsmodell, som är ett system för att definiera åtkomsträttigheter till filer och kataloger. Linux filsystems säkerhetsmodell bidrar till att säkerställa att användarna endast har tillgång till sina egna filer och inte till andras filer eller till själva operativsystemet.
Den sista byggstenen är den programvara som krävs för att implementera alla dessa funktioner. Linux använder en tvådelad mjukvaruimplementering som ett sätt att förbättra både systemets och programmerarnas effektivitet.
Figur 1: Linux tvådelade mjukvaruimplementering av filsystemet.
Den första delen av denna tvådelade implementering är Linux virtuella filsystem. Detta virtuella filsystem tillhandahåller en enda uppsättning kommandon för kärnan och utvecklare för att få tillgång till alla typer av filsystem. Programvaran för det virtuella filsystemet anropar den specifika enhetsdrivrutin som krävs för att få kontakt med de olika typerna av filsystem. De filsystemspecifika enhetsdrivrutinerna är den andra delen av genomförandet. Enhetsdrivrutinen tolkar standarduppsättningen av filsystemkommandon till sådana som är specifika för typen av filsystem på partitionen eller den logiska volymen.
Katalogstruktur
Som vanligtvis mycket organiserad Jungfru tycker jag om att saker och ting lagras i mindre, organiserade grupper snarare än i en stor hink. Användningen av kataloger hjälper mig att kunna lagra och sedan hitta de filer jag vill ha när jag letar efter dem. Kataloger kallas också för mappar eftersom de kan ses som mappar där filerna förvaras i ett slags fysisk skrivbordsanalogi.
I Linux och många andra operativsystem kan kataloger struktureras i en trädliknande hierarki. Linux katalogstruktur är väldefinierad och dokumenterad i Linux Filesystem Hierarchy Standard (FHS). Referenser till dessa kataloger vid åtkomst till dem görs genom att använda de sekventiellt djupare katalognamnen som är sammankopplade med snedstreck (/), t.ex. /var/log och /var/spool/mail. Dessa kallas för sökvägar.
I följande tabell finns en mycket kortfattad förteckning över de standardiserade, välkända och definierade Linux-katalogerna på högsta nivå och deras syften.
| Katalog | Beskrivning |
|---|---|
| / (root filesystem) | Rotfilssystemet är den översta nivåns katalog i filsystemet. Den måste innehålla alla filer som krävs för att starta upp Linuxsystemet innan andra filsystem monteras. Den måste innehålla alla nödvändiga körbara filer och bibliotek som krävs för att starta upp de övriga filsystemen. När systemet har startats upp monteras alla andra filsystem på vanliga, väldefinierade monteringspunkter som underkataloger till rotfilssystemet. |
| /bin | Katalogen /bin innehåller användarens körbara filer. |
| /boot | Innehåller den statiska starthanteraren och kärnans körbara filer och konfigurationsfiler som krävs för att starta upp en Linux-dator. |
| /dev | Denna katalog innehåller enhetsfilerna för varje hårdvaruenhet som är ansluten till systemet. Detta är inte enhetsdrivrutiner, utan filer som representerar varje enhet på datorn och underlättar åtkomsten till dessa enheter. |
| /etc | Innehåller de lokala systemkonfigurationsfilerna för värddatorn. |
| /home | Hemkatalogens lagring av användarfiler. Varje användare har en underkatalog i /home. |
| /lib | Innehåller delade biblioteksfiler som krävs för att starta upp systemet. |
| /media | En plats för att montera externa flyttbara medieenheter, t.ex. USB-minnesenheter som kan vara anslutna till värden. |
| /mnt | En tillfällig monteringspunkt för vanliga filsystem (dvs. inte flyttbara medier) som kan användas medan administratören reparerar eller arbetar med ett filsystem. |
| /opt | Optionella filer, t.ex. leverantörslevererade tillämpningsprogram, bör ligga här. |
| /root | Detta är inte filsystemet root (/). Det är hemkatalogen för root-användaren. |
| /sbin | Systemets binära filer. Detta är körbara filer som används för systemadministration. |
| /tmp | Temporär katalog. Används av operativsystemet och många program för att lagra tillfälliga filer. Användare kan också lagra filer tillfälligt här. Observera att filer som lagras här kan raderas när som helst utan föregående meddelande. |
| /usr | Det här är filer som kan delas och endast kan läsas, inklusive körbara binärer och bibliotek, man-filer och andra typer av dokumentation. |
| /var | Filer med variabla data lagras här. Detta kan inkludera saker som loggfiler, MySQL och andra databasfiler, datafiler för webbservern, e-postinkorgar och mycket mer. |
De kataloger och deras underkataloger som visas i tabell 1, tillsammans med deras underkataloger, som har en kråkfärgad bakgrund betraktas som en integrerad del av rotfilssystemet. Det innebär att de inte kan skapas som ett separat filsystem och monteras vid start. Detta beror på att de (närmare bestämt deras innehåll) måste finnas vid uppstart för att systemet ska kunna starta upp ordentligt.
Katalogerna /media och /mnt är en del av rotfilsystemet, men de ska aldrig innehålla några data. Snarare är de helt enkelt tillfälliga monteringspunkter. De återstående katalogerna, de som inte har någon bakgrundsfärg i tabell 1 behöver inte finnas med under uppstartssekvensen, utan kommer att monteras senare, under startsekvensen som förbereder värddatorn för att utföra användbart arbete.
Se till att läsa den officiella webbsidan Linux Filesystem Hierarchy Standard (FHS) för att få mer information om var och en av dessa kataloger och deras många underkataloger. Wikipedia har också en bra beskrivning av FHS. Denna standard bör följas så noga som möjligt för att säkerställa operativ och funktionell konsistens. Oavsett vilka filsystemtyper som används på en värd är denna hierarkiska katalogstruktur densamma.
Linux enhetlig katalogstruktur
I vissa PC-operativsystem som inte är Linux, om det finns flera fysiska hårddiskar eller flera partitioner, tilldelas varje disk eller partition en enhetsbeteckning. Det är nödvändigt att veta på vilken hårddisk en fil eller ett program finns, till exempel C: eller D:. Sedan anger du enhetsbokstaven som ett kommando, till exempel D:, för att byta till enheten D:, och sedan använder du kommandot cd för att byta till rätt katalog för att hitta den önskade filen. Varje hårddisk har sitt eget separata och kompletta katalogträd.
Linux filsystem förenar alla fysiska hårddiskar och partitioner i en enda katalogstruktur. Allt börjar högst upp – i rotkatalogen (/). Alla andra kataloger och deras underkataloger ligger under den enda Linuxrotkatalogen. Detta innebär att det bara finns ett enda katalogträd att söka efter filer och program i.
Detta kan bara fungera eftersom ett filsystem, t.ex. /home, /tmp, /var, /opt eller /usr kan skapas på separata fysiska hårddiskar, en annan partition eller en annan logisk volym än / (rot)-filsystemet och sedan monteras på en monteringspunkt (katalog) som en del av rotfilsystemträdet. Även flyttbara enheter som t.ex. en USB-minne eller en extern USB- eller ESATA-hårddisk monteras på rotfilsystemet och blir en integrerad del av det katalogträdet.
En bra anledning att göra detta är uppenbart vid en uppgradering från en version av en Linuxdistribution till en annan, eller vid byte från en distribution till en annan. I allmänhet, och bortsett från eventuella uppgraderingsverktyg som dnf-upgrade i Fedora, är det klokt att då och då formatera om hårddisken/ hårddiskarna som innehåller operativsystemet under en uppgradering för att på ett positivt sätt ta bort all skräp som har samlats med tiden. Om /home är en del av rotfilssystemet kommer det också att formateras om och måste då återställas från en säkerhetskopia. Genom att ha /home som ett separat filsystem kommer det att vara känt för installationsprogrammet som ett separat filsystem och formateringen av det kan hoppas över. Detta kan också gälla /var där databas, e-postinkorgar, webbplats och andra variabla användar- och systemdata lagras.
Det finns andra skäl för att behålla vissa delar av Linux katalogträd som separata filsystem. För länge sedan, när jag ännu inte var medveten om de potentiella problemen med att ha alla nödvändiga Linux-kataloger som en del av filsystemet / (root), lyckades jag till exempel fylla min hemkatalog med ett stort antal mycket stora filer. Eftersom varken /home-katalogen eller /tmp-katalogen var separata filsystem utan helt enkelt underkataloger till rotfilssystemet fylldes hela rotfilssystemet. Det fanns inget utrymme kvar för operativsystemet att skapa tillfälliga filer eller utöka befintliga datafiler. Till att börja med började tillämpningsprogrammen klaga på att det inte fanns något utrymme för att spara filer, och sedan började själva operativsystemet bete sig mycket märkligt. Genom att starta upp till enanvändarläge och rensa bort de felande filerna i min hemkatalog kunde jag komma igång igen. Jag installerade sedan Linux på nytt med en ganska vanlig installation med flera filsystem och kunde förhindra att fullständiga systemkrascher inträffade igen.
Jag hade en gång en situation där en Linux-värd fortsatte att köras, men hindrade användaren från att logga in med hjälp av GUI-skrivbordet. Jag kunde logga in med hjälp av kommandoradsgränssnittet (CLI) lokalt med hjälp av en av de virtuella konsolerna och på distans med hjälp av SSH. Problemet var att filsystemet /tmp hade fyllts och att vissa temporära filer som krävs för GUI-skrivbordet inte kunde skapas vid inloggningstillfället. Eftersom CLI-inloggningen inte kräver att filer skapas i /tmp hindrade inte bristen på utrymme där mig från att logga in med CLI. I det här fallet var katalogen /tmp ett separat filsystem och det fanns gott om utrymme i den volymgrupp som den logiska volymen /tmp ingick i. Jag utökade helt enkelt den logiska volymen /tmp till en storlek som motsvarade min nya uppfattning om hur mycket tillfälligt filutrymme som behövdes på den värddatorn och problemet var löst. Observera att denna lösning inte krävde någon omstart, och så snart /tmp-filsystemet hade utökats kunde användaren logga in på skrivbordet.
En annan situation inträffade när jag arbetade som labbadministratör på ett stort teknikföretag. En av våra utvecklare hade installerat ett program på fel plats (/var). Programmet kraschade eftersom filsystemet /var var fullt och loggfilerna, som lagras i /var/log på det filsystemet, kunde inte kompletteras med nya meddelanden på grund av platsbrist. Systemet fortsatte dock att fungera eftersom de kritiska filsystemen / (root) och /tmp inte fylldes upp. Att ta bort det felande programmet och installera det på nytt i filsystemet /opt löste problemet.
Filsystemtyper
Linux stöder läsning av omkring 100 partitionstyper; det kan skapa och skriva till endast några få av dessa. Men det är möjligt – och mycket vanligt – att montera filsystem av olika typer på samma rotfilssystem. I det här sammanhanget talar vi om filsystem i termer av de strukturer och metadata som krävs för att lagra och hantera användardata på en partition på en hårddisk eller en logisk volym. Den fullständiga listan över partitionstyper för filsystem som Linux fdisk-kommando känner igen finns här, så att du kan få en känsla för den höga grad av kompatibilitet som Linux har med väldigt många typer av system.
0 Empty 24 NEC DOS 81 Minix / old Lin bf Solaris 1 FAT12 27 Hidden NTFS Win 82 Linux swap / So c1 DRDOS/sec (FAT- 2 XENIX root 39 Plan 9 83 Linux c4 DRDOS/sec (FAT- 3 XENIX usr 3c PartitionMagic 84 OS/2 hidden or c6 DRDOS/sec (FAT- 4 FAT16 <32M 40 Venix 80286 85 Linux extended c7 Syrinx 5 Extended 41 PPC PReP Boot 86 NTFS volume set da Non-FS data 6 FAT16 42 SFS 87 NTFS volume set db CP/M / CTOS / . 7 HPFS/NTFS/exFAT 4d QNX4.x 88 Linux plaintext de Dell Utility 8 AIX 4e QNX4.x 2nd part 8e Linux LVM df BootIt 9 AIX bootable 4f QNX4.x 3rd part 93 Amoeba e1 DOS access a OS/2 Boot Manag 50 OnTrack DM 94 Amoeba BBT e3 DOS R/O b W95 FAT32 51 OnTrack DM6 Aux 9f BSD/OS e4 SpeedStor c W95 FAT32 (LBA) 52 CP/M a0 IBM Thinkpad hi ea Rufus alignment e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a5 FreeBSD eb BeOS fs f W95 Ext'd (LBA) 54 OnTrackDM6 a6 OpenBSD ee GPT10 OPUS 55 EZ-Drive a7 NeXTSTEP ef EFI (FAT-12/16/11 Hidden FAT12 56 Golden Bow a8 Darwin UFS f0 Linux/PA-RISC b12 Compaq diagnost 5c Priam Edisk a9 NetBSD f1 SpeedStor14 Hidden FAT16 <3 61 SpeedStor ab Darwin boot f4 SpeedStor16 Hidden FAT16 63 GNU HURD or Sys af HFS / HFS+ f2 DOS secondary17 Hidden HPFS/NTF 64 Novell Netware b7 BSDI fs fb VMware VMFS18 AST SmartSleep 65 Novell Netware b8 BSDI swap fc VMware VMKCORE1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid fd Linux raid auto1c Hidden W95 FAT3 75 PC/IX bc Acronis FAT32 L fe LANstep1e Hidden W95 FAT1 80 Old Minix be Solaris boot ff BBT
Det huvudsakliga syftet med att stödja förmågan att läsa så många partitionstyper är att möjliggöra kompatibilitet och åtminstone viss driftskompatibilitet med andra datorsystems filsystem. De valmöjligheter som finns när man skapar ett nytt filsystem med Fedora visas i följande lista.
- btrfs
- cramfs
- ext2
- ext3
- ext4
- fat
- gfs2
- hfsplus
- minix
- msdos
- ntfs
- reiserfs
- vfat
- xfs
.
Andra distributioner har stöd för att skapa olika filsystemtyper. CentOS 6 stöder till exempel endast skapandet av de filsystem som är markerade med fet stil i listan ovan.
Montering
Uttrycket ”att montera” ett filsystem i Linux hänvisar tillbaka till datorernas tidiga dagar då ett band eller ett flyttbart diskpaket behövde monteras fysiskt på en lämplig drivenhet. Efter att ha placerats fysiskt på enheten skulle filsystemet på diskpaketet monteras logiskt av operativsystemet för att göra innehållet tillgängligt för åtkomst för operativsystemet, tillämpningsprogram och användare.
En monteringspunkt är helt enkelt en katalog, som vilken annan som helst, som skapas som en del av rotfilssystemet. Så till exempel är filsystemet home monterat på katalogen /home. Filsystem kan monteras i monteringspunkter på andra filsystem som inte är rotfiler, men detta är mindre vanligt. Linux rotfilsystem monteras på rotkatalogen (/) mycket tidigt i uppstartssekvensen. Andra filsystem monteras senare, av Linux startprogram, antingen rc under SystemV eller systemd i nyare Linuxversioner. Montering av filsystem under uppstartsprocessen hanteras av konfigurationsfilen /etc/fstab. Ett enkelt sätt att komma ihåg det är att fstab står för ”file system table” (filsystemtabell) och är en lista över filsystem som ska monteras, deras utsedda monteringspunkter och eventuella alternativ som kan behövas för specifika filsystem.
Filsystem monteras på en befintlig katalog/monteringspunkt med hjälp av kommandot mount. I allmänhet ska en katalog som används som monteringspunkt vara tom och inte innehålla några andra filer. Linux hindrar inte användare från att montera ett filsystem på ett filsystem som redan finns där eller på en katalog som innehåller filer. Om du monterar ett filsystem på en befintlig katalog eller ett befintligt filsystem kommer det ursprungliga innehållet att döljas och endast innehållet i det nymonterade filsystemet kommer att vara synligt.
Slutsats
Jag hoppas att en del av den eventuella förvirringen kring begreppet filsystem har klarats upp av den här artikeln. Det tog lång tid och en mycket hjälpsam mentor för mig att verkligen förstå och uppskatta komplexiteten, elegansen och funktionaliteten hos Linux filsystem i alla dess betydelser.
Om du har frågor kan du lägga till dem i kommentarerna nedan så ska jag försöka besvara dem.
Nästa månad
Ett annat viktigt begrepp är att för Linux är allt en fil. Detta koncept har några intressanta och viktiga praktiska tillämpningar för användare och systemadministratörer. Anledningen till att jag nämner detta är att du kanske vill läsa min artikel ”Allt är en fil” innan den artikel jag planerar för nästa månad om katalogen /dev.