Kan du blanda SATA- och NVMe-enheter i samma Btrfs-filsystem?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Can You Mix SATA and NVMe Devices in the Same Btrfs Filesystem? - Zima Store Online

Ja, Btrfs kan använda båda, men allokeringen följer profilen och det tillgängliga utrymmet - inte ett garanterat snabbt lager - så prestanda och felbeteende blir ojämna.

Beslutet är viktigt när en ägare av en hem-NAS vill lägga till NVMe-kapacitet i ett befintligt SATA-Btrfs-filsystem. De två konkurrerande tillstånden är en stödd pool med blandade enheter och ingen automatisk cachelagring eller nivåindelning. Börja med en sparad konfiguration och data som kan tas bort, observera en gren i taget och avbryt om testet ökar risken för dataförlust, behörighetsproblem eller otillgänglighet.

Definiera villkoren bakom beslutet om ett Btrfs-filsystem med blandade enheter

Dokumentera miljön innan du ändrar något: programvaru- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symptomet. Baslinjen måste innehålla tillräckligt med detaljer för att återskapa situationen där en ägare av en hem-NAS vill lägga till NVMe-kapacitet i ett befintligt SATA-Btrfs-filsystem.

Den första kandidaten är en stödd pool med blandade enheter. Den andra är ingen automatisk cachelagring eller nivåindelning. Den aktuella hanteringen av Btrfs med flera enheter definierar mekanismen eller kommandogränsen som används i testet; den ersätter inte observationer från just den här hemservern.

Skriv ned godkännandekriteriet och stoppkriteriet innan du kör särskiljningstestet. Ett godkänt resultat måste ändra de bevis som förutsägs av en gren samtidigt som orelaterade tjänster förblir oförändrade; ett underkänt resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa korrigeringar.

Testa påståendet utan att sänka det ursprungliga kravet

Använd detta särskiljningstest: skapa en blandad pool som kan tas bort, kontrollera chunk-allokeringen, fyll den förbi en enhetsklass och testa degraderat läge samt ersättningsbeteende. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidsinställning konstanta så att resultatet kan hänföras till den ändrade variabeln.

Använd Btrfs-beteende i kärnan för att välja det fält som faktiskt kan skilja grenarna åt, och fånga dess tidsstämpel, slutstatus, feltext, enhets- eller ögonblicksbildsidentitet, fördröjning, överförda byte, behörigheter och återställningstillstånd. En felfri kommandokörning räcker inte när identitet, hållbarhet eller applikationstillstånd är det som testas.

Upprepa testet en gång efter en omstart, återanslutning, ommontering eller kall cache när den händelsen ingår i det ursprungliga villkoret. Om den första körningen är destruktiv eller miljön inte kan återställas ska du avbryta och återskapa testet på en kopia som kan tas bort i stället.

btrfs filesystem usage /mnt/pool
btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/pool

Tolka godkända, underkända och avvikande resultat

GODKÄNT: data- och metadataprofilerna förblir möjliga att uppfylla och den uppmätta prestandan motsvarar arbetsbelastningens mål. Dokumentera den exakta versionen, identiteten och arbetsbelastningen som godkändes så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.

UNDERKÄNT: den minsta eller långsammaste enheten begränsar en speglad profil, eller så stannar inte aktiva data på NVMe. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsekvens kan påverka båda; isolera dessa gemensamma beroenden innan du går vidare.

AVVIKANDE ELLER TVETYDIGT RESULTAT: behåll NVMe som ett separat filsystem eller cachelager när förutsägbar nivåindelning krävs. Spara loggarna och kör inte reparations-, rensnings-, förstörings-, ompartitionerings- eller rekursiva ägarändringskommandon förrän det finns en återställningsbar kopia.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Bekräfta beslutet under den ursprungliga arbetsbelastningen

Tillämpa den åtgärd som motsvarar den observerade grenen och upprepa sedan det ursprungliga villkoret i stället för en förenklad ersättning. Beslutet gäller endast när data- och metadataprofilerna förblir möjliga att uppfylla och den uppmätta prestandan motsvarar arbetsbelastningens mål under två cykler eller genom den relevanta omstarten, viloläget, avbrottet eller belastningsövergången.

Använd de separata datajobben för att kontrollera det närmast beroende arbetsflödet, men behåll den ursprungliga utlösaren oförändrad. Orelaterade datauppsättningar, delningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsåtgång.

Stoppgränsen är tydlig: om den minsta eller långsammaste enheten begränsar en speglad profil, eller om aktiva data inte stannar på NVMe, återgår du till den senast verifierade konfigurationen, behåller bevisen och går endast vidare till ett djupare plattforms- eller hårdvarutest när grenen kan reproduceras.

När målresultatet har uppnåtts jämför du det med verifieringen efter ändringen så att korrigeringen inte flyttar risken till en närliggande tjänst. Ett lyckat måltest med ett nytt fel i säkerhetskopiering, identitet, tidsgräns eller tillgänglighet är fortfarande en misslyckad ändring.

Vanliga frågor

För ett Btrfs-filsystem med blandade enheter gäller de återstående frågorna vanligtvis om Btrfs automatiskt håller metadata på NVMe, om RAID1 kräver lika stora enheter och om NVMe kan tas bort senare. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.

Godkännandegränsen flyttas inte: data- och metadataprofilerna förblir möjliga att uppfylla och den uppmätta prestandan motsvarar arbetsbelastningens mål. Om ett uppföljande villkor ändrar filsystemet, identiteten, nätverkssökvägen eller applikationsversionen ska du endast upprepa det särskiljningstest som påverkas av ändringen.

Sluta bredda experimentet när den minsta eller långsammaste enheten begränsar en speglad profil, eller när aktiva data inte stannar på NVMe. Behåll då NVMe som ett separat filsystem eller cachelager när förutsägbar nivåindelning krävs; bevara bevisen innan du eskalerar till plattforms-, lagrings- eller hårdvaruansvarig.

Kommer Btrfs automatiskt att hålla metadata på NVMe?

Inte bara för att en enhet är snabbare. Allokeringsprofiler skapar inte automatiskt ett prestandalager.

Kräver RAID1 lika stora enheter?

Nej, men användbart utrymme och chunk-placering beror på enheternas storlek och profilbegränsningar.

Kan NVMe tas bort senare?

Ja, när de återstående enheterna kan uppfylla allokeringarna; kör en plan för borttagning av enheten och behåll säkerhetskopior.

För ett Btrfs-filsystem med blandade enheter är det praktiska svaret fortfarande villkorat: data- och metadataprofilerna förblir möjliga att uppfylla och den uppmätta prestandan motsvarar arbetsbelastningens mål. När den minsta eller långsammaste enheten begränsar en speglad profil, eller när aktiva data inte stannar på NVMe, behåll NVMe som ett separat filsystem eller cachelager när förutsägbar nivåindelning krävs; en delvis lyckad lösning som inte klarar den ursprungliga arbetsbelastningen är inte kompatibilitet.