Förstå katalogstorlekar i Azure NetApp Files
När en fil skapas i en katalog läggs en post till i en dold indexfil i Azure NetApp Files-volymen. Den här indexfilen hjälper till att hålla reda på befintliga innoder i en katalog och hjälper till att påskynda uppslagsbegäranden för kataloger med ett stort antal filer. När poster läggs till i den här filen ökar filstorleken (men minskar aldrig) med en hastighet av cirka 512 byte per post beroende på filnamnets längd. Längre filnamn lägger till mer storlek i filen. Symboliska länkar lägger också till poster i den här filen. Det här konceptet kallas katalogstorlek, vilket är ett vanligt element i alla Linux-baserade filsystem. Katalogstorlek är inte det maximala totala antalet filer i en enda Azure NetApp Files-volym. Det bestäms av värdetmaxfiles
.
När en ny katalog skapas förbrukar den som standard 4 KiB (4 096 byte) eller åtta block på 512 byte. Du kan visa storleken på en nyligen skapad katalog från en Linux-klient med hjälp av stat-kommandot.
# mkdir dirsize
# stat dirsize
File: ‘dirsize’
Size: 4096 Blocks: 8 IO Block: 32768 directory
Katalogstorlekar är specifika för en enskild katalog och kombineras inte i storlekar. Om det till exempel finns 10 kataloger i en volym kan var och en närma sig storleksgränsen på 320 MiB-kataloger på en enda volym.
Kontrollera om en katalog närmar sig gränsstorleken
För en 320-MiB-katalog är antalet block 655360, där varje blockstorlek är 512 byte. (Det vill: 320x1024x1024/512.) Det här talet översätts till cirka 4–5 miljoner filer maximalt för en 320 MiB-katalog. Det faktiska antalet maximala filer kan dock vara lägre, beroende på faktorer som antalet filer med icke-ASCII-tecken i katalogen.
Du kan använda stat
kommandot från en klient för att se om en katalog närmar sig den maximala storleksgränsen för katalogmetadata (320 MB). Om du når den maximala storleksgränsen för en enskild katalog för Azure NetApp Files uppstår felet No space left on device
.
För en katalog på 320 MB är antalet block 655 360, där varje blockstorlek är 512 byte. (Det vill: 320x1024x1024/512.) Det här antalet översätts till cirka 4 miljoner filer maximalt för en katalog på 320 MB. Det faktiska antalet maximala filer kan dock vara lägre, beroende på faktorer som antalet filer med icke-ASCII-tecken i katalogen. Information om hur du övervakar maxdirsize finns i Övervakning maxdirsize
.
Överväganden för katalogstorlek
När du hanterar en miljö med högt antal filer bör du överväga följande rekommendationer:
- Azure NetApp Files-volymer stöder upp till 320 MiB för katalogstorlekar. Det här värdet kan inte ökas.
- När en volyms katalogstorlek har överskridits visar klienterna ett out-of-space-fel även om det finns ledigt utrymme i volymen.
- För vanliga volymer motsvarar en 320 MiB-katalogstorlek ungefär 4–5 miljoner filer i en enda katalog. Det här värdet är beroende av filnamnslängderna.
- Stora volymer har en annan arkitektur än vanliga volymer.
- Höga filantal i en enskild katalog kan medföra prestandaproblem vid sökning. När det är möjligt begränsar du den totala storleken på en enskild katalog till 2 MiB (ungefär 27 000 filer) när frekventa sökningar behövs.
- Om det behövs fler filer i en enda katalog justerar du förväntningarna på sökprestanda i enlighet med detta. Även om Azure NetApp Files indexerar katalogfillistorna för prestanda kan sökningar ta lite tid med höga filantal.
- Undvik flata kataloglayouter när du utformar filsystemet. Information om olika metoder för kataloglayouter finns i Om kataloglayouter.
- Lös problem där katalogstorleken har överskridits och nya filer inte kan skapas, ta bort eller flytta filer från den relevanta katalogen.
Om kataloglayouter
Värdet maxdirsize
kan skapa problem när du använder flata katalogstrukturer, där en enskild mapp innehåller miljontals filer på en enda nivå. Mappstrukturer där filer, mappar och undermappar varvat har en låg inverkan på maxdirsize
. Det finns flera katalogstrukturmetoder.
En flat katalogstruktur är en enda katalog med många filer under samma katalog.
En bred katalogstruktur innehåller många kataloger på toppnivå med filer spridda över alla kataloger.
En djup katalogstruktur innehåller färre kataloger på toppnivå med många underkataloger. Även om den här strukturen ger färre filer per mapp kan filsökvägslängder bli ett problem om kataloglayouterna är för djupa och filsökvägarna blir för långa. Mer information om filsökvägslängder finns i Förstå filsökvägslängder i Azure NetApp Files.
Effekten av flata katalogstrukturer i Azure NetApp Files
Flata katalogstrukturer (många filer i en eller flera kataloger) har en negativ effekt på en mängd olika filsystem, Azure NetApp-filvolymer eller andra. Potentiella problem är:
- Minnesbelastning
- CPU-användning
- Nätverksprestanda/svarstid (särskilt vid massa frågor om filer,
GETATTR
åtgärder,READDIR
åtgärder)
På grund av utformningen av stora Volymer i Azure NetApp Files är effekten av maxdirsize
unik. Azure NetApp Files stora volym maxdirsize
påverkas unikt på grund av dess design. Till skillnad från en vanlig volym använder en stor volym fjärrhård länkar i Azure NetApp Files för att omdirigera trafik mellan olika lagringsenheter för att ge mer skalning och prestanda. När du använder platta kataloger finns det ett högre förhållande mellan interna fjärrhårda länkar till lokala filer. Dessa fjärrhårdlänkar räknas mot det totala maxdirsize
värdet, så en stor volym kan närma sig gränsen maxdirsize
snabbare än en vanlig volym.
Om en enskild katalog till exempel har miljontals filer och genererar ungefär 85 % fjärrhårda länkar för filsystemet kan du förvänta maxdirsize
dig att vara uttömd med nästan dubbelt så mycket som en vanlig volym.
För bästa resultat med katalogstorlekar i Azure NetApp Files:
- Undvik flata katalogstrukturer i Azure NetApp Files. Breda eller djupa katalogstrukturer fungerar bäst, förutsatt att sökvägslängden för filen eller mappen inte överskrider NAS-protokollstandarderna.
- Om det inte går att undvika flata katalogstrukturer övervakar
maxdirsize
du katalogerna.
Bildskärm maxdirsize
För en enskild katalog använder du stat
kommandot för att hitta katalogstorleken.
# stat /mnt/dir_11/c5
stat
Även om kommandot kan användas för att kontrollera katalogstorleken för en viss katalog kanske det inte är lika effektivt att köra det individuellt mot en enda katalog. Om du vill se en lista över de största katalogstorlekarna sorterade från största till minsta, tillhandahåller följande kommando det samtidigt som du utelämnar ögonblicksbildkataloger från frågan.
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn
Kommentar
Katalogstorleken som rapporterats av stat-kommandot är i byte. Den storlek som rapporteras i sökkommandot finns i KiB.
Exempel
# 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
I föregående är katalogstorleken /mnt/dir_11/c5
316 084 KiB (308,6 MiB), som närmar sig gränsen på 320 MiB. Det motsvarar cirka 4,1 miljoner filer.
# ls /mnt/dir_11/c5 | wc -l
4171624
I det här fallet bör du överväga korrigerande åtgärder som att flytta eller ta bort filer.