Varför stannar en Btrfs-balans efter att data har flyttats till en större enhet?

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.

Why Does a Btrfs Balance Stall After Moving Data to a Larger Drive?

En Btrfs-balansering kan verka ha stannat efter att en större disk har lagts till, eftersom flytten fortfarande behöver ledigt utrymme för chunk-arbetsyta och kan behöva flytta hela filsystemet.

Att ersätta eller kopiera data till en större enhet gör inte automatiskt alla Btrfs-blockgrupper kompakta, jämnt fördelade eller möjliga att flytta. En balansering arbetar på blockgruppsnivå, skapar tillfällig arbetsyta, uppdaterar metadata och kan begränsas av den långsammaste enheten, ögonblicksbilder, kontrollsummor eller någon annan exklusiv åtgärd. Det första steget är att skilja en faktiskt fastnad flytt från en långsam fullständig balansering som fortfarande gör framsteg.

Bekräfta om balanseringen körs, är pausad eller väntar

Kontrollera balanseringsstatus, antal bearbetade chunks, kärnloggen, diskgenomströmningen och fördröjningen per enhet. Notera om kommandot körs i förgrunden eller bakgrunden, är pausat eller avbrutet, eller automatiskt återupptogs efter en omstart.

En balansering kan ägna lång tid åt att flytta en hårt använd blockgrupp innan den synliga räknaren ändras. ArchWiki:s Btrfs-vägledning visar hur du använder status för balansering och filsystemsanvändning för att skilja fortsatt arbete från ett kommando som redan har stoppats.

Om det inte förekommer någon I/O, ingen statusändring och kärnloggen rapporterar ett fel ska du behandla det som stoppat, inte som långsamt. Spara det första felmeddelandet innan du startar om balanseringen med andra filter.

Kontrollera att den större enheten och filsystemet har storleksändrats

Jämför den fysiska enhetsstorleken, partitionsstorleken, Btrfs-enhetsstorleken och filsystemets allokering. En större ersättningsdisk kan fortfarande visa den gamla partitionsgränsen eller den gamla Btrfs-enhetsstorleken.

Bekräfta varje lager i ordning: hårdvarukapacitet, partitionstabell, blockenhet, Btrfs-enhetsinventering och filsystemets allokering. SUSE dokumenterar att enheten måste förstoras före filsystemet, så en balansering kan inte använda kapacitet som Btrfs ännu inte ser.

ZimaSpace-artikeln om kapacitet som inte ökar efter byte av disk ger en närliggande lagerkontroll innan någon flytt får skulden.

Skilj mellan lediga byte och ledigt chunk-arbetsutrymme

Jämför den totala enhetsstorleken med den mängd som redan har tilldelats Btrfs-blockgrupper. Ett filsystem kan visa lediga byte för användare men ändå sakna ett helt oallokerat område som är tillräckligt stort för att skapa den tillfälliga blockgrupp som behövs för flytten.

Btrfs-dokumentationen om balansering förklarar att flytten behöver helt oanvänd arbetsyta för blockgrupper. Detta skiljer sig från vanligt ledigt utrymme på filnivå och kan orsaka ENOSPC under balanseringen.

Om arbetsutrymmet är begränsat ska du först återta helt oanvända blockgrupper med ett snävt användningsfilter i stället för att starta en ny fullständig balansering. Radera inte ögonblicksbilder urskillningslöst innan deras bidrag till chunk-allokeringen har mätts.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Kontrollera om en fullständig balansering startades utan filter

Granska det ursprungliga kommandot. En balansering utan data- eller metadatafilter försöker flytta hela filsystemet, även när det egentliga målet bara är att komprimera chunks med låg användning eller flytta allokeringar från en viss enhet.

En fullständig balansering kan ta många timmar eller dagar eftersom varje vald blockgrupp skrivs om. Linux-manualen för btrfs-balance varnar för att körning utan filter flyttar data och metadata över hela filsystemet och uppdaterar alla blockpekare.

Använd statusutdata och tidigare sk historik för att identifiera de aktiva filtren. Avbryt och starta inte om upprepade gånger, eftersom avbrutna balanseringar kan lämna delvis fyllda blockgrupper som fortsätter att förbruka arbetsutrymme.

Kontrollera långsamma enheter, fel och konkurrerande exklusiva åtgärder

Kontrollera SMART-data, transportfel, länkåterställningar, USB- eller SATA-timeouter och fördröjningen per enhet. Balanseringshastigheten begränsas av läsningar från gamla platser, skrivningar till nya platser, kontrollsummeverifiering och metadatauppdateringar.

Kontrollera även scrub, tillägg eller borttagning av enheter, storleksändring av filsystemet, radering av ögonblicksbilder, send eller receive samt annat lagringsarbete. Red Hats administrationsguide för Btrfs beskriver ändringar av enheter och balansering som flyttåtgärder, så överlappande underhåll kan skapa kraftig konkurrens även när ingen disk har gått sönder.

Om en enhet visar upprepade återställningar eller extrem fördröjning ska du pausa balanseringen och felsöka den sökvägen innan du tvingar fram mer flytt. Att fortsätta med en instabil enhet kan förvandla ett prestandaproblem till ett återställningsproblem.

Använd snäva filter och begränsningar vid en kontrollerad omstart

När det aktuella tillståndet har sparats ska du börja med det minst riskfyllda filtret som riktar in sig på tomma eller sparsamt använda blockgrupper. Begränsa antalet chunks per körning så att varje resultat kan observeras innan omfattningen ökas.

Öka användningströskeln gradvis och hantera data och metadata separat. Metadataflytt kan generera många ytterligare uppdateringar och behöver inte komprimeras aggressivt bara för att den genomsnittliga användningen ser låg ut.

Pausa, återuppta eller avbryt via de stödda balanseringskontrollerna i stället för att döda processen. Bekräfta att den aktuella blockgruppen slutförs och att det sparade balanseringstillståndet överensstämmer med nästa åtgärd.

Verifiera fördelning och kapacitet efter balanseringen

Jämför allokeringen per enhet, data- och metadataprofiler, oanvänt arbetsutrymme, filsystemsanvändning och antalet flyttade chunks före och efter den kontrollerade balanseringen.

Ett lyckat resultat innebär inte nödvändigtvis perfekt jämn byte-användning över varje disk. Linux-kärnans översikt listar integrerat stöd för flera enheter och storleksändring online, så det slutliga testet bör fokusera på giltiga profiler, användbar allokering, felfria enheter och tillräckligt arbetsutrymme för framtida skrivningar.

Problemet är löst när balanseringen slutförs eller når det avsedda filtrerade omfånget, den större enheten får nya allokeringar, ledigt chunk-arbetsutrymme har återställts och normala skrivningar, ögonblicksbilder, scrub och omstarter fungerar utan att balanseringen oväntat startar om.