Varför ser lagringsanvändningen olika ut i NAS-gränssnittet och filsystemet?

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.

NAS- och filsystemsanvändning skiljer sig ofta åt eftersom deras räknare omfattar olika lager, såsom ögonblicksbilder, metadata, reserver, glesa extentar och delade block.

En delad mapp kan innehålla 4 TB synliga filer medan NAS-panelen rapporterar 5,2 TB använt utrymme. Inget av totalvärdena behöver vara fel. Den ena vyn kan summera logiska filstorlekar, medan den andra rapporterar fysisk allokering i lagringspoolen, inklusive data som det aktuella katalogträdet inte kan se eller koppla till synliga filer i samma lagringspool.

Logisk filstorlek och allokerat utrymme besvarar olika frågor

En fil anger en logisk längd för applikationer, men filsystemet allokerar lagring i block eller extentar. Glesa filer kan innehålla oallokerade hål, medan små filer kan förbruka en hel allokeringsenhet plus metadata. Att summera filnamn behöver därför inte motsvara förbrukad kapacitet.

En Linux-förklaring av skillnaderna mellan du och df visar att katalogsummor och verktyg för ledigt filsystemutrymme granskar olika redovisningslager. Deras resultat kan legitimt skilja sig åt under flera förhållanden.

Komprimering och blockdelning skapar ytterligare oklarheter. Två logiska filer kan referera till samma fysiska block, eller så kan komprimerade data uppta mindre utrymme än den angivna längden. Ett användargränssnitt måste välja om det ska rapportera logiskt ägarskap, exklusiv allokering, refererade byte eller total förbrukning i poolen.

Ögonblicksbilder och reserver håller block utanför det aktiva trädet

När du tar bort en fil försvinner den från den aktuella katalogen, men en ögonblicksbild kan behålla dess gamla block. Poolmetadata, paritet, kontrollsummor, copy-on-write-historik och reserverad kapacitet kan också räknas som använda eller otillgängliga utan att visas i en delad mapp.

En praktisk genomgång av utrymme för ögonblicksbilder förklarar att ögonblicksbilder fortsätter att referera till ändrade eller borttagna data. Utrymmet frigörs först när ingen bevarad ögonblicksbild längre behöver dessa block.

Ett annat dolt fall är en borttagen fil som fortfarande är öppen av en process. Dess sökväg försvinner, så en genomgång av katalogen missar den, men blocken förblir allokerade tills processen stänger filhandtaget. Panelen ser poolens användning medan det aktiva trädet verkar mindre.

När olika totalvärden signalerar ett verkligt problem

Olika redovisningslager ursäktar inte kontinuerligt växande, oförklarad användning. En avstannad policy för ögonblicksbilder, en skenande logg, en övergiven containerdatauppsättning, en replikeringsreserv eller ett filsystemfel kan skapa en verklig kapacitetsrisk.

En guide om borttagna öppna filer visar hur borttagna filer som fortfarande är öppna kan hittas genom processinspektion. Denna mekanism har ett specifikt kännetecken, inte bara en vag avvikelse.

Förklaringen gäller inte heller om båda verktygen påstår sig visa samma datauppsättning, ögonblicksbildsomfattning, enheter och allokeringsgrund men fortfarande skiljer sig kraftigt efter uppdatering. Decimal- kontra binära enheter förklarar bara en begränsad procentuell skillnad. Bekräfta definitionerna innan du betraktar någon av vyerna som auktoritativ.

Jämför kapaciteten från poolen till de synliga filerna

Registrera poolens totala, allokerade och lediga utrymme samt datauppsättningens refererade och exklusiva utrymme, ögonblicksbilder, reserver och synliga filtotaler vid samma tidpunkt. Notera om värdena är logiska eller fysiska och om komprimering och delade block ingår. Kontrollera om det finns borttagna filer som fortfarande är öppna utan att ta bort något.

Koppla inventeringen till NAS-lagringens beteende, eftersom vektordatabaser och containrar kan placera data i datauppsättningar utanför den synliga delade mappen. Kartlägg varje tjänsts sökväg till den underliggande datauppsättningen.

Jämför uppifrån och ned från poolen: poolens allokering bör enligt plattformens definitioner motsvara aktiva datauppsättningar, ögonblicksbilder, metadata och reserver. Undersök den kategori som växer mellan ögonblicksbilderna. Ta inte bort synliga filer enbart för att tillfredsställa en räknare som främst påverkas av bevarad historik.

Teknik- och AI-hubb

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.