Waarom loopt een Btrfs-balancering vast nadat gegevens naar een grotere schijf zijn verplaatst?
Een Btrfs-balance kan lijken vast te lopen nadat een grotere schijf is toegevoegd, omdat er voor het verplaatsen nog vrije chunk-werkruimte nodig is en mogelijk het hele bestandssysteem wordt verwerkt.
Het vervangen of kopiëren van gegevens naar een groter apparaat maakt niet automatisch elke Btrfs-blokgroep compact, gelijkmatig verdeeld of geschikt voor verplaatsing. Een balance werkt op blokgroepniveau, maakt tijdelijke werkruimte aan, werkt metagegevens bij en kan worden beperkt door het langzaamste apparaat, snapshots, checksums of een andere exclusieve bewerking. De eerste taak is om onderscheid te maken tussen een daadwerkelijk vastgelopen verplaatsing en een trage volledige balance die nog steeds voortgang boekt.
Controleer of de balance actief, gepauzeerd of wachtend is
Controleer de balance-status, het aantal verwerkte chunks, het kernel-logboek, de schijfdoorvoer en de latentie per apparaat. Noteer of de opdracht op de voorgrond of op de achtergrond draait, is gepauzeerd of geannuleerd, of na een herstart automatisch is hervat.
Een balance kan lange tijd bezig zijn met het verplaatsen van één intensief gebruikte blokgroep voordat de zichtbare teller verandert. De Btrfs-richtlijnen van ArchWiki tonen hoe u de balance-status en het bestandssysteemgebruik kunt gebruiken om aanhoudende werkzaamheden te onderscheiden van een opdracht die al is gestopt.
Als er geen I/O of statuswijziging is en het kernel-logboek een fout meldt, behandel dit dan als gestopt in plaats van traag. Bewaar het eerste foutbericht voordat u de balance met andere filters opnieuw start.
Controleer of het grotere apparaat en bestandssysteem zijn vergroot
Vergelijk de fysieke apparaatgrootte, partitiegrootte, Btrfs-apparaatgrootte en bestandssysteemtoewijzing. Een grotere vervangende schijf kan nog steeds de oude partitiegrens of de oude Btrfs-apparaatgrootte tonen.
Controleer elke laag in deze volgorde: hardwarecapaciteit, partitietabel, blokapparaat, Btrfs-apparaatinventaris en bestandssysteemtoewijzing. SUSE documenteert dat het apparaat eerst moet worden vergroot voordat het bestandssysteem wordt uitgebreid, zodat een balance geen capaciteit kan gebruiken die Btrfs nog niet ziet.
Het ZimaSpace-artikel over capaciteit die niet toeneemt na het vervangen van een schijf biedt de aanvullende controle van deze lagen voordat een verplaatsing de schuld krijgt.
Maak onderscheid tussen vrije bytes en vrije chunk-werkruimte
Vergelijk de totale apparaatgrootte met de hoeveelheid die al aan Btrfs-blokgroepen is toegewezen. Een bestandssysteem kan gebruikers vrije bytes tonen en toch geen volledig niet-toegewezen gebied hebben dat groot genoeg is om de tijdelijke blokgroep aan te maken die voor een verplaatsing nodig is.
De Btrfs-balance-documentatie legt uit dat voor verplaatsing volledig ongebruikte blokgroep-werkruimte nodig is. Dit verschilt van gewone vrije ruimte op bestandsniveau en kan tijdens een balance ENOSPC veroorzaken.
Als de werkruimte beperkt is, maakt u eerst volledig ongebruikte blokgroepen vrij met een smal gebruiksfilter, in plaats van nog een volledige balance te starten. Verwijder snapshots niet zonder onderscheid voordat u hun bijdrage aan de chunk-toewijzing hebt gemeten.
Controleer of een volledige balance zonder filters is gestart
Bekijk de oorspronkelijke opdracht. Een balance zonder gegevens- of metagegevensfilters probeert het hele bestandssysteem te verplaatsen, zelfs wanneer het werkelijke doel alleen is om licht gebruikte chunks te comprimeren of toewijzingen van één apparaat weg te verplaatsen.
Een volledige balance kan vele uren of dagen duren omdat elke geselecteerde blokgroep opnieuw wordt geschreven. De Linux-handleiding voor btrfs-balance waarschuwt dat een uitvoering zonder filters gegevens en metagegevens over het hele bestandssysteem verplaatst en alle blokpointers bijwerkt.
Gebruik de statusuitvoer en de eerdere shellgeschiedenis om de actieve filters te achterhalen. Annuleer en start de balance niet steeds opnieuw, omdat onderbroken balances gedeeltelijk gevulde blokgroepen kunnen achterlaten die werkruimte blijven gebruiken.
Controleer trage apparaten, fouten en concurrerende exclusieve bewerkingen
Controleer SMART-gegevens, transportfouten, linkresets, USB- of SATA-time-outs en de latentie per apparaat. De snelheid van een balance wordt beperkt door het lezen van oude locaties, het schrijven naar nieuwe locaties, checksum-verificatie en metagegevensupdates.
Controleer ook scrub, het toevoegen of verwijderen van apparaten, het vergroten van het bestandssysteem, het verwijderen van snapshots, send of receive en andere opslagwerkzaamheden. De Btrfs-beheergids van Red Hat beschrijft apparaatwijzigingen en balance als verplaatsingsbewerkingen, waardoor overlappend onderhoud zware concurrentie kan veroorzaken, zelfs wanneer geen schijf defect is.
Als één apparaat herhaaldelijk resets of een extreem hoge latentie vertoont, pauzeer dan de balance en stel eerst dat pad vast voordat u verdere verplaatsingen forceert. Doorgaan met een instabiel apparaat kan een prestatieprobleem veranderen in een herstelprobleem.
Gebruik smalle filters en limieten voor een gecontroleerde herstart
Bewaar de huidige status en start vervolgens met het filter met het laagste risico dat lege of licht gebruikte blokgroepen target. Beperk het aantal chunks per uitvoering, zodat u elk resultaat kunt observeren voordat u de omvang vergroot.
Verhoog de gebruiksdrempel geleidelijk en behandel gegevens en metagegevens afzonderlijk. Het verplaatsen van metagegevens kan veel extra updates veroorzaken en hoeft niet agressief te worden gecomprimeerd alleen omdat de gemiddelde benutting laag lijkt.
Pauzeer, hervat of annuleer via de ondersteunde balance-besturingen in plaats van het proces te beëindigen. Controleer of de huidige blokgroep wordt voltooid en of de opgeslagen balance-status overeenkomt met de volgende actie.
Controleer de verdeling en capaciteit na de balance
Vergelijk de toewijzing per apparaat, gegevens- en metagegevensprofielen, niet-toegewezen werkruimte, het bestandssysteemgebruik en het aantal verplaatste chunks vóór en na de gecontroleerde balance.
Een succesvol resultaat betekent niet noodzakelijk dat elk station exact evenveel bytes gebruikt. Het Linux-kerneloverzicht vermeldt geïntegreerde ondersteuning voor meerdere apparaten en online vergroten. De eindcontrole moet daarom gericht zijn op geldige profielen, bruikbare toewijzing, gezonde apparaten en voldoende werkruimte voor toekomstige schrijfbewerkingen.
Het probleem is opgelost wanneer de balance is voltooid of het beoogde gefilterde bereik heeft bereikt, het grotere apparaat nieuwe toewijzingen ontvangt, vrije chunk-werkruimte is hersteld en normale schrijfbewerkingen, snapshots, scrub en herstarts werken zonder dat de balance onverwacht opnieuw begint.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
