Delen via

Mapgrootten in Azure NetApp Files begrijpen

  • Artikel

Wanneer een bestand in een map wordt gemaakt, wordt een vermelding toegevoegd aan een verborgen indexbestand binnen het Azure NetApp Files-volume. Dit indexbestand helpt bij het bijhouden van de bestaande inodes in een map en helpt bij het versnellen van zoekaanvragen voor mappen met een groot aantal bestanden. Wanneer vermeldingen aan dit bestand worden toegevoegd, neemt de bestandsgrootte toe (maar neemt nooit af) met een snelheid van ongeveer 512 bytes per vermelding, afhankelijk van de lengte van de bestandsnaam. Langere bestandsnamen voegen meer grootte toe aan het bestand. Symbolische koppelingen voegen ook vermeldingen toe aan dit bestand. Dit concept wordt de mapgrootte genoemd. Dit is een gemeenschappelijk element in alle linux-bestandssysteemen. Mapgrootte is niet het maximumaantal bestanden in één Azure NetApp Files-volume. Dat wordt bepaald door de maxfiles waarde.

Wanneer een nieuwe map wordt gemaakt, verbruikt deze standaard 4 KiB (4.096 bytes) of acht 512-byteblokken. U kunt de grootte van een zojuist gemaakte map van een Linux-client weergeven met behulp van de opdracht stat.

# mkdir dirsize 
# stat dirsize 
File: ‘dirsize’ 
Size: 4096            Blocks: 8          IO Block: 32768  directory

Mapgrootten zijn specifiek voor één map en worden niet gecombineerd in grootten. Als er bijvoorbeeld 10 directory's in een volume staan, kan elke map de limiet van 320 MiB in één volume benaderen.

Bepalen of een map de limietgrootte nadert

Voor een map van 320 MiB is het aantal blokken 655360, waarbij elke blokgrootte 512 bytes is. (Dat wil gezegd, 320x1024x1024/512.) Dit getal wordt omgezet in ongeveer 4-5 miljoen bestanden voor een map van 320-MiB. Het werkelijke aantal maximumbestanden kan echter lager zijn, afhankelijk van factoren zoals het aantal bestanden met niet-ASCII-tekens in de map.

U kunt de stat opdracht van een client gebruiken om te zien of een map de maximale grootte voor mapmetagegevens nadert (320 MB). Als u de maximale grootte voor één map voor Azure NetApp Files bereikt, treedt de fout No space left on device op.

Voor een map van 320 MB is het aantal blokken 655.360, waarbij elke blokgrootte 512 bytes is. (Dat wil gezegd, 320x1024x1024/512.) Dit getal wordt omgezet in ongeveer 4 miljoen bestanden voor een map van 320 MB. Het werkelijke aantal maximumbestanden kan echter lager zijn, afhankelijk van factoren zoals het aantal bestanden met niet-ASCII-tekens in de map. Zie Bewaking maxdirsizevoor meer informatie over het bewaken van de maxdirsize.

Overwegingen voor mapgrootte

Houd rekening met de volgende aanbevelingen bij het omgaan met een omgeving met een hoog aantal bestanden:

  • Azure NetApp Files-volumes ondersteunen maximaal 320 MiB voor mapgrootten. Deze waarde kan niet worden verhoogd.
  • Zodra de mapgrootte van een volume is overschreden, geven clients een fout met onvoldoende ruimte weer, zelfs als er vrije ruimte beschikbaar is in het volume.
  • Voor normale volumes is een mapgrootte van 320 MiB gelijk aan ongeveer 4-5 miljoen bestanden in één map. Deze waarde is afhankelijk van de lengte van de bestandsnaam.
  • Grote volumes hebben een andere architectuur dan gewone volumes.
  • Het hoge aantal bestanden in één map kan prestatieproblemen opleveren bij het zoeken. Beperk indien mogelijk de totale grootte van één map tot 2 MiB (ongeveer 27.000 bestanden) wanneer frequente zoekopdrachten nodig zijn.
    • Als er meer bestanden nodig zijn in één map, past u de verwachtingen voor zoekprestaties dienovereenkomstig aan. Hoewel Azure NetApp Files de lijst met mapbestanden indexeert voor prestaties, kunnen zoekopdrachten enige tijd duren met een hoog aantal bestanden.
  • Vermijd platte mapindelingen bij het ontwerpen van uw bestandssysteem. Zie Over mapindelingen voor informatie over verschillende benaderingen voor mapindelingen.
  • Om problemen op te lossen waarbij de mapgrootte is overschreden en nieuwe bestanden niet kunnen worden gemaakt, verwijdert of verplaatst u bestanden uit de relevante map.

Over mapindelingen

De maxdirsize waarde kan zorgen maken wanneer u platte mapstructuren gebruikt, waarbij één map miljoenen bestanden op één niveau bevat. Mapstructuren waarbij bestanden, mappen en submappen worden gekruist, hebben een lage invloed op maxdirsize. Er zijn verschillende methoden voor directorystructuur.

Een platte mapstructuur is één map met veel bestanden onder dezelfde map.

Diagram van een platte mapstructuur.

Een brede mapstructuur bevat veel mappen op het hoogste niveau met bestanden verspreid over alle mappen.

Diagram van een brede mapstructuur.

Een diepe mapstructuur bevat minder mappen op het hoogste niveau met veel submappen. Hoewel deze structuur minder bestanden per map biedt, kunnen bestandspadlengten een probleem worden als mapindelingen te diep zijn en bestandspaden te lang worden. Zie Bestandspadlengten begrijpen in Azure NetApp Files voor meer informatie over de lengte van bestandspaden.

Diagram van een diepe mapstructuur.

Impact van platte mapstructuren in Azure NetApp Files

Platte mapstructuren (veel bestanden in één of enkele mappen) hebben een negatief effect op een breed scala aan bestandssystemen, Azure NetApp File-volumes of andere. Mogelijke problemen zijn:

  • Geheugendruk
  • CPU-gebruik
  • Netwerkprestaties/latentie (met name tijdens massaquery's van bestanden, GETATTR bewerkingen, READDIR bewerkingen)

Vanwege het ontwerp van grote volumes van Azure NetApp Files is de impact maxdirsize uniek. Grote volumes maxdirsize van Azure NetApp Files worden uniek beïnvloed vanwege het ontwerp. In tegenstelling tot een normaal volume gebruikt een groot volume externe vaste koppelingen in Azure NetApp Files om verkeer om te leiden naar verschillende opslagapparaten om meer schaal en prestaties te bieden. Wanneer u platte mappen gebruikt, is er een hogere verhouding van interne externe harde koppelingen naar lokale bestanden. Deze externe harde koppelingen tellen mee ten opzichte van de totale maxdirsize waarde, zodat een groot volume de maxdirsize limiet sneller kan benaderen dan een normaal volume.

Als een enkele map bijvoorbeeld miljoenen bestanden bevat en ongeveer 85% externe harde koppelingen voor het bestandssysteem genereert, kunt u verwachten dat maxdirsize u bijna twee keer zoveel verbruikt als een normaal volume.

Voor de beste resultaten met mapgrootten in Azure NetApp Files:

  • Vermijd platte mapstructuren in Azure NetApp Files. Brede of diepe mapstructuren werken het beste, mits de padlengte van het bestand of de map niet hoger is dan de NAS-protocolstandaarden.
  • Als platte mapstructuren onvermijdelijk zijn, controleert u de maxdirsize mappen.

Monitor maxdirsize

Gebruik voor één map de stat opdracht om de mapgrootte te vinden.

# stat /mnt/dir_11/c5

Hoewel de stat opdracht kan worden gebruikt om de mapgrootte van een specifieke map te controleren, is het mogelijk niet zo efficiënt om deze afzonderlijk uit te voeren op één map. Als u een lijst met de grootste mapgrootten wilt zien die van groot naar klein zijn gesorteerd, geeft de volgende opdracht aan dat u momentopnamemappen uit de query weglaat.

# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn

Notitie

De mapgrootte die wordt gerapporteerd door de opdracht stat, bevindt zich in bytes. De grootte die is gerapporteerd in de opdracht Zoeken, bevindt zich in KiB.

Voorbeeld

# stat /mnt/dir_11/c5 

  File: ‘/mnt/dir_11/c5’ 

  Size: 322396160       Blocks: 632168     IO Block: 32768  directory 
 
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 
316084 /mnt/dir_11/c5 

3792 /mnt/dir_19 

3792 /mnt/dir_16

In het vorige geval is de mapgrootte 316.084 KiB (308,6 MiB), die de limiet van /mnt/dir_11/c5 320-MiB nadert. Dat komt overeen met ongeveer 4,1 miljoen bestanden.

# ls /mnt/dir_11/c5 | wc -l
4171624

In dit geval kunt u corrigerende acties overwegen, zoals het verplaatsen of verwijderen van bestanden.

Meer informatie