Welke gedeelde map gebruikt onverwacht veel NAS-ruimte?

De map die onverwacht NAS-ruimte gebruikt, is niet altijd de grootste map die in de bestandsbrowser wordt weergegeven.

Begin bij het aangekoppelde bestandssysteem en beperk de zoekopdracht vervolgens per directoryniveau. Dit voorkomt dat u een zichtbare share de schuld geeft terwijl snapshots, prullenbakken, applicatiegegevens, verwijderde bestanden of inode-druk capaciteit gebruiken buiten het zicht dat u eerst opende.

Begin bij het bestandssysteem, niet bij de mapnaam

Bevestig welk bestandssysteem de getroffen share ondersteunt en noteer de gebruikte, beschikbare en inode-waarden. De df-weergave rapporteert totaalwaarden op bestandssysteemniveau, terwijl een share-browser alleen objecten rapporteert die hij kan zien en tellen.

Controleer het share-pad ten opzichte van het aankoppelpunt. Een bind mount, containervolume of ontbrekende data-pool mount kan ervoor zorgen dat een bekend pad schrijft naar de kleinere systeempartitie in plaats van naar de bedoelde opslagpool.

Rangschik gedeelde mappen op toegewezen ruimte

Voer een samenvatting van mappen op diepte één uit in de root van de data-pool, waarbij u op hetzelfde bestandssysteem blijft. Het doel is om de grootste mappen op het eerste niveau te rangschikken voordat u dieper ingaat op het grootste resultaat. Herhaal dit op het volgende niveau totdat de groei gekoppeld is aan een project, gebruiker, mediatheek, back-upset of applicatiepad.

Gebruik toegewezen grootte voor capaciteitsvragen. De schijnbare bestandsgrootte kan verschillen door bestandssysteemblokken, sparse bestanden, harde koppelingen, compressie en deduplicatie, dus een desktop-bestandsbeheerder komt mogelijk niet overeen met de NAS-toewijzing.

Controleer snapshots, prullenbakken en verborgen gebruikers

Als zichtbare mappen minder ruimte innemen dan het volumegebruik, controleer dan snapshot-retentie, prullenbakken van shares, pakketgegevens, containervolumes, miniaturen, tijdelijke uploadgebieden en back-upversiegeschiedenis. Deze gebruikers kunnen buiten de share-root liggen, ook al behoort de werklast die ze heeft gecreëerd tot die share.

Een groot logbestand kan ook worden losgekoppeld terwijl het proces er nog naar blijft schrijven. In dat geval blijft een verwijderd bestand dat nog open is door het bestandssysteem geteld, maar verdwijnt het uit de maptotalen. Controleer ook inode-uitputting door veel kleine bestanden wanneer schrijfacties mislukken terwijl er nog gigabytes beschikbaar zijn.

Bevestig wat u veilig kunt verwijderen

Verwijder niet zomaar de eerste grote map die u vindt. Identificeer de eigenaar, actieve processen, retentieregels en back-upstatus. Snoei snapshots via het bestandssysteem of de NAS-interface, roteer logs via de dienst die ze beheert en controleer containervolumes voordat u afbeeldingen of databases verwijdert.

Voer na elke gecontroleerde wijziging dezelfde metingen van bestandssysteem en mappen opnieuw uit. Een schoon resultaat betekent niet alleen meer vrije ruimte; het is een gedocumenteerde groeibron, een veilige retentie-beslissing en een waarschuwing of quotum die de volgende toename zichtbaar maakt.

FAQ

Waarom komen de totalen van gedeelde mappen niet overeen met het volumegebruik?

Ze meten verschillende reikwijdtes. Het volume omvat bestandssysteemmetadata en verborgen gebruikers, terwijl het maptotaal alleen bereikbare bestanden onder dat pad omvat en mogelijk schijnbare in plaats van toegewezen grootte rapporteert.

Kunnen veel kleine bestanden ruimte innemen zonder één grote map?

Ja. Kleine bestanden gebruiken toewijzingsblokken en inodes. Een cache- of mail-achtige map kan bestandsrecords uitputten, zelfs als geen enkel bestand groot lijkt.

Waarom geeft het verwijderen van bestanden niet direct vrije NAS-ruimte?

Een snapshot kan nog steeds naar de blokken verwijzen, een prullenbak kan het bestand vasthouden, of een lopend proces kan een verwijderd bestand openhouden. Identificeer welke situatie van toepassing is voordat u services herstart of retentie snoeit.