En NAS kan inte återfå ledigt utrymme efter att en stor fil försvunnit eftersom borttagning av dess synliga namn bara är en del av lagringsåtervinningen. En papperskorg, filsystemssnapshot, backupversion eller körande process kan fortfarande hålla filens underliggande block.
Rätt åtgärd beror på vad som fortfarande refererar till dessa block. Kontrollera delningen, snapshot-lagret, körande tjänster och poolredovisning i den ordningen. Rensa inte alla snapshots eller starta om hela NAS innan du identifierat vilket lager som äger det saknade utrymmet.
Kärnorsaken: Filen är borta men dess block refereras fortfarande
En fil har en synlig katalogpost och lagringsblock som innehåller dess data. Att ta bort posten gör att filen försvinner från mappen, men filsystemet kan återanvända dess block först efter att varje kvarvarande referens har släppts. Den skillnaden förklarar varför en lyckad borttagning inte alltid ger en lika stor ökning av ledigt utrymme.
På en Linux-baserad NAS kan en tjänst hålla en redan borttagen fil öppen. Kärnan bevarar datan tills den sista filbeskrivaren stängs, även om filbläddrare och normala katalogskanningar inte längre kan se den. Red Hats förklaring av behållning av diskutrymme för borttagna filer som fortfarande är öppna visar varför stopp eller en mjuk omstart av den hållande processen frigör utrymme som borttagning ensam inte gjorde.
Andra hållare fungerar ovanför lagret för öppna filer. En nätverksåtervinningsservice kan flytta filen istället för att ta bort den, medan en copy-on-write-snapshot avsiktligt bevarar de äldre blocken för återställning. Det synliga resultatet är liknande – lite eller ingen återvunnen kapacitet – men den säkra korrigerande åtgärden är annorlunda.
Vilket NAS-lager håller fortfarande de borttagna data?
Börja med att jämföra vad som ändrades efter borttagning. Filnamnet kan ha flyttats till en dold papperskorgskatalog, live-datasetet kan ha krympt medan snapshot-användningen ökade, eller poolens total kan förbli högre än de filer som katalogverktyg kan räkna. Dessa mönster begränsar utrymmeshållaren utan destruktiv rensning.
| Vad du observerar | Sannolik utrymmeshållare | Vad du ska kontrollera | Säker nästa åtgärd |
|---|---|---|---|
| Filen försvinner, men en papperskorgsmapp växer | Delningspapperskorg | Papperskorg för samma delning och användare | Granska och töm rätt återvinningsplats |
| Användningen av live-datasetet minskar, men poolanvändningen ändras knappt | Snapshots eller behållna versioner | Snapshot-utrymme och behållningstider | Ta bara bort versioner utanför återställningspolicyn |
| Filsystemanvändningen är högre än de synliga katalogtotalerna | Raderad fil hålls öppen | Processer med öppna filer som inte längre är länkade | Starta om eller ladda om tjänsten varslar mjukt |
| En delning krymper, men totalt ledigt utrymme i poolen ändras inte | Barn-dataset, reservation eller annan arbetsbelastning | Användning per dataset, applikation och backupjobb | Korrigera den faktiska användaren istället för delningen |
| Ledigt utrymme ändras kort efter borttagningen | Väntande redovisning eller bakgrundsrensning | Färska poolmått efter att aktiviteten lugnat sig | Vänta och uppdatera innan du gör en ny ändring |
En papperskorg är det enklaste fallet. Sambas VFS recycle-bin-beteende fångar upp borttagningsförfrågningar och flyttar filer till ett arkiv istället för att ta bort dem omedelbart. En fil som raderats via en SMB-delning kan därför finnas kvar på samma lagringspool även om den försvunnit från sin ursprungliga mapp.
Snapshots är mindre uppenbara eftersom de kan bevara block utan att behålla en annan vanlig fil i den aktiva katalogen. När en snapshot refererar till tillståndet före borttagning, tar bort den levande filen bara bort den aktuella referensen. Detta exempel på snapshot-utrymmesredovisning visar varför en snapshot kan återvinna lite när andra snapshots fortfarande refererar till samma block.
Pool- och delningsvärden kan också mäta olika omfång. En delning kan rapportera sitt dataset eller kvot, medan lagringspanelen inkluderar barn-dataset, applikationsdata, backupversioner, reservationer och snapshot-hållna block. Jämför likadant med likadant innan du drar slutsatsen att borttagningen misslyckades.
Återvinn utrymme utan att förstöra återställningshistorik
Återvinning bör gå från reversibla kontroller till permanent borttagning. Uppdatera först kapacitetsvyn och bekräfta att du läser rätt pool, dataset och delning. En kort redovisningsfördröjning kan vara normal; en bestående skillnad efter att aktiviteten lugnat sig indikerar att en annan referens eller lagringsomfång fortfarande behöver undersökas.
- Bekräfta att den raderade filen saknas från den ursprungliga delningen och inte flyttades eller bytte namn av en applikation.
- Inspektera papperskorgen kopplad till just den delningen och användarkontot.
- Granska snapshots och backup-bevarande efter datum, dataset och uppskattat återvinningsbart utrymme.
- Jämför filsystemanvändning med synliga katalogsummor för att identifiera dold allokering.
- Kontrollera barn-dataset, applikationsvolymer, kvoter och reservationer innan du ändrar poolen.
- Frigör den bekräftade hållaren genom dess normala behållning, tjänst eller administrativa kontroll.
När filsystemets användning förblir högre än den synliga katalogsumman, undersök borttagna filer som fortfarande är öppna. lsof-kontrollen för öppna filer använder lsof +L1 för att lista filer utan kvarvarande kataloglänk. Identifiera processen och använd dess normala omladdnings- eller mjuka omstartsväg; avsluta inte en okänd databas- eller lagringstjänst enbart för att återvinna utrymme.
För data som hålls av snapshots, uppskatta vad varje ändring i behållning faktiskt kommer att återvinna innan återställningspunkter tas bort. Block som delas av flera snapshots kan förbli allokerade tills den sista refererande snapshoten upphör, så att ta bort en snapshot kan frigöra mycket mindre utrymme än dess uppenbara historikstorlek antyder. Bevara återställningsvärdet först och justera behållningen medvetet.
Om rutinmässiga borttagningar upprepade gånger pressar poolen nära full kapacitet är problemet också kapacitetsplanering. Behållning av papperskorg, snapshots, applikationer och säkerhetshistorik behöver marginal utöver live-filens storlek, så användbar NAS-kapacitetsplanering måste inkludera dessa mindre synliga konsumenter.
Vanliga frågor
Varför återvann tömning av NAS-papperskorgen bara en del av utrymmet?
Samma block kan fortfarande refereras av snapshots, säkerhetskopior eller en öppen process. Att tömma papperskorgen tar bara bort den hållaren; det åsidosätter inte andra referenser eller frigör utrymme reserverat av en annan dataset.
Hur lång tid bör en NAS ta för att visa det nyligen frigjorda utrymmet?
En kort fördröjning medan lagringsredovisning och bakgrundsarbete stabiliseras kan vara normalt. Om värdet förblir oförändrat efter att instrumentpanelen och filsystemstatistiken uppdaterats, kontrollera snapshots, borttagna öppna filer, kvoter och om det visade numret representerar andelen eller hela poolen.
Förhindrar RAID att borttagna filer frigör utrymme?
RAID tillämpar normalt borttagningen över den aktiva arrayen; det bevarar inte den gamla filen som återställningshistorik. Papperskorgar och snapshots är separata lager, medan RAID-skyddsbegränsningar handlar om tillgänglighet snarare än återställning av borttagna filer eller utrymmesbehållning.
Support och tips
Mer att läsa

Varför blir en RAID-array inaktiv efter ett strömavbrott?
En inaktiv array betyder ofta att metadata hittades men att systemet inte hade tillräckligt med förtroende eller medlemmar för att starta den säkert efter...

Vilka är riskerna med att tvinga en saknad RAID-medlem att komma online igen?
Tvångsalternativ kan kringgå säkerhetskontroller kring föråldrad metadata, smutsig paritet, saknade skrivningar eller aktiva pooler; undersök och bevara bevis innan du använder dem.

Hur man skiljer en dålig SATA-kabel från en felande NAS-enhet
Spåra om fel följer med disken eller stannar kvar i SATA-vägen, och separera transporträknare från bevis på mediehälsa innan hårdvara byts ut.

