Archive for the Category » filsystemer «

Søndag, 4 august, 2013 | Author:

Jeg havde en strømafbrydelse påvirke min server store MD RAID matrix. Snarere end at lade serveren som en helhed være nede, mens du venter på at gennemføre en fsck, Jeg havde det starte op uden den store vifte, så jeg kunne køre fsck manuelt.

Dog, når du kører den manuelt indså jeg, jeg havde ingen mulighed for at vide, hvor langt det var, og hvor lang tid det ville tage at fuldføre. Dette er især problematisk med sådan en bred vifte. Med lidt søgning fandt jeg spidsen af tilføje-C parameter, når du ringer fsck. Jeg kunne ikke finde denne i dokumentationen dog: fsck –hjælp viste ingen sådan mulighed.

Muligheden viser sig at være ext4-specifikke, og viser således et perfekt funktionelle statuslinje med en procent-indikator. For at finde den information, i stedet for “fsck –hjælpe” eller “mand fsck”, du nødt til at indtaste “fsck.ext4 –hjælpe” eller “mand fsck.ext4”. 🙂

Del
Søndag, 4 august, 2013 | Author:

Historie

Meget havde ændret sig siden jeg sidst nævnte min personlige server – Det er vokset med stormskridt (det nu har en 7TB MD RAID6) og det havde for nylig blevet genopbygget med Ubuntu Server.

Arch var aldrig en fejltagelse. Arch Linux havde allerede lært mig så meget om Linux (og vil fortsætte med at gøre det på min anden desktop). Men Arch klart kræver mere tid og opmærksomhed, end jeg gerne bruge på en server. Ideelt ville jeg foretrække at være i stand til at glemme alt om serveren et stykke tid indtil en påmindelse e-mail, siger “um … Der er et par opdateringer, du bør se på, kammerat.”

Rummet er ikke gratis – og hverken er plads

Muligheden for at migrere til Ubuntu var, at jeg var løbet tør for SATA porte, de porte, der kræves til at forbinde harddiske til resten af ​​computeren – at 7TB RAID bruger en masse porte! Jeg havde endda givet væk min meget gamle 200GB harddisk, som det tog op en af ​​disse havne. Jeg advarede også modtageren, at diskens SMART overvågning angivet, at det var upålidelige. Som en midlertidig løsning på den manglende SATA-porte, Jeg havde selv migreret serverens OS til et sæt af fire USB-sticks i en MD RAID1. Crazy. Jeg kender. Jeg var ikke alt for glad for hastigheden. Jeg besluttede at gå ud og købe en ny pålidelig harddisk og et SATA udvidelseskort at gå med det.

Serverens primære Arch partition blev bruger omkring 7 GB disk. En stor bid af det var en swap fil, cachelagrede data og ellers diverse eller unødvendige filer. Samlet den faktiske størrelse af OS, herunder /hjem mappe, var kun ca 2GB. Det fik mig til at kigge ind i en super-hurtig SSD drev, tænker måske en mindre måske ikke være så dyrt. Det viste sig, at den billigste ikke-SSD drev jeg kunne finde faktisk koste mere end en af ​​disse relativt små SSD'er. Yay for mig. 🙂

Choice? Woah?!

Ved valg af OS, Jeg havde allerede besluttet, at det ikke ville være Arch. Ud af alle de andre populære distributioner, Jeg er mest fortrolige med Ubuntu og CentOS. Fedora var også en mulighed – men jeg havde ikke for alvor endnu anset det for en server. Ubuntu vandt runde.

Den næste beslutning, jeg havde at gøre ikke forekomme for mig indtil Ubiquity (Ubuntus installationsguiden) spurgte den af ​​mig: Hvordan at oprette skillevægge.

Jeg var ny til at bruge SSD'er i Linux – Jeg er udmærket klar over faldgruberne ikke bruger dem korrekt, hovedsagelig på grund af deres risiko for dårlig levetid hvis de misbruges.

Jeg ønskede ikke at bruge en dedikeret swap partition. Jeg har planer om at opgradere serverens bundkort / CPU / hukommelse ikke alt for langt ude i fremtiden. Baseret på, at jeg besluttede jeg vil lægge swap på en swap-fil på den eksisterende md RAID. Swap vil ikke være særlig hurtig, men dens eneste formål vil være for den sjældne lejlighed, når noget er gået galt, og hukommelsen er ikke tilgængelig.

Dette så forlod mig for at give den rodstien den fulde 60GB ud af en Intel 330 SSD. Jeg overvejede at adskille / hjem, men det syntes bare lidt meningsløst, givet hvor lidt blev brugt i fortiden. Jeg først oprette partition med LVM – noget, jeg har for nylig gjort, når jeg oprettet en Linux boks (virkelig, der er ingen undskyldning for ikke at bruge LVM). Når det kom til den del, hvor jeg vil konfigurere filsystem, Jeg klikkede på drop-down og instinktivt valgt ext4. Så bemærkede jeg btrfs på den samme liste. Hæng på!!

Men hvad?

Btrfs (“smør-eff-ess”, “bedre eff-ess”, “bee-tree-eff-ess”, eller hvad du har lyst til på dagen) er et relativt nyt filsystem udviklet for at bringe Linux’ filsystemet kapaciteter tilbage på sporet med den nuværende filsystem tech. Den eksisterende King-of-the-Hill filsystem, “ext” (den aktuelle version hedder ext4) er rigtig god – men det er begrænset, fast i en gammel paradigme (tænke på en helt ny F22 Raptor vs. en F4 Phantom med en halv Jested forsøg på en ækvivalens opgradering) og det er usandsynligt at være i stand til at konkurrere om meget lang med nyere Enterprise filsystemer, såsom Oracles ZFS. Btrfs har stadig en lang vej at gå, og er stadig betragtes som eksperimentelle (afhængigt af, hvem man spørger, og hvilke funktioner du har brug for). Mange anser det for at være stabil i grundlæggende brug – men ingen vil gøre nogen garantier. Og, naturligvis, alle siger at gøre og teste backups!

Mooooooo

Den mest fundamentale forskel mellem ext og btrfs er, at btrfs er en “Ko” eller “Kopiering på Skriv” filsystem. Det betyder, at data aldrig er faktisk bevidst overskrevet af filsystem er indvendige. Hvis du skriver en ændring til en fil, btrfs vil skrive dine ændringer til en ny placering på fysiske medier og vil opdatere de interne henvisninger til at henvise til den nye placering. Btrfs går et skridt videre i at disse interne pointers (benævnt metadata) er også Ko. Ældre versioner af ext blot ville have overskrevne data. Ext4 ville bruge en Journal for at sikre, at korruption ikke vil forekomme, bør netstikket være hevet ud på det mest ubelejlige tidspunkt. Tidsskriftet resulterer i et lignende antal trin for at opdatere data. Med en SSD, den underliggende hardware driver en lignende CoW proces uanset hvad filsystem du bruger. Dette skyldes, at SSD-drev ikke kan faktisk overskrive data – de skal kopiere data (med dine ændringer) til en ny placering, og derefter slettes den gamle blok helt. En optimering på dette område er, at en SSD måske ikke engang slette den gamle blok, men snarere blot gøre et notat til at slette blokken på et senere tidspunkt, når tingene ikke så travlt. Slutresultatet er, at SSD-drev passer meget godt med en ko filsystem og ikke udføre såvel med non-CoW filsystemer.

For at gøre tingene interessant, Ko i filsystemet nemt går hånd i hånd med en funktion kaldet deduplikering. Dette giver mulighed for to (eller mere) identiske blokke af data, der skal lagres ved hjælp af kun en enkelt kopi, spare plads. Med ko, hvis en deduplicated fil er ændret, den separate tvilling vil ikke blive påvirket, da den ændrede fil data vil være blevet skrevet til en anden fysisk blok.

Ko til gengæld gør snapshotting forholdsvis let at gennemføre. Når et snapshot er gjort systemet blot registrerer det nye øjebliksbillede som en gentagelse af alle data og metadata inden for lydstyrken. Med ko, når der foretages ændringer, af øjebliksbillede data forbliver intakt, og et sammenhængende billede af filsystemet status på tidspunktet for snapshot blev kan opretholdes.

En ny ven

Med ovenstående i tankerne, især da Ubuntu har gjort btrfs tilgængelig som en install-time option, Jeg regnede med det ville være et godt tidspunkt at dykke ned btrfs og udforske lidt. 🙂

Del 2 kommer snart …

Del