Filsystem har alltid olika begränsningar och som utökats med tiden (tänk FAT, VFAT, NTFS) i tex. antal tecken i filnamn, hur många filer/direktorys som kan lagras i roten eller underdirektory etc.
NTFS har tex. ett tak på max antal filer vid 4,294,967,295 st per disk-volym (32-bitars räknare på inoder eller motsvarande filräknare uppenbarligen, det är sådana saker som skvallrar vilken tidsepok filsystemet skrevs i en gång i tiden och är närmast omöjligt att göra något åt senare eftersom det får konsekvenser precis överallt) och man kommer att slå i denna tak långt innan man fyllt med tomma filer/direktorys i en ordinär SSD-storlek på typiskt 240 GB.
Normal konsumentbruk så är det sällan man går över enstaka miljoner filer även på stora diskar som 8 TB, men det är klart, skall man ha lagringssystem i PByte-storlek med småfiler så finns det potentiellt tak för NTFS långt innan dess arktitektmässiga max-storlek är nådd och en av de grejorna som begränsar är just max antal filer filsystemet kan hantera.
Det här är dock aldrig ett reellt problem såvida inte dumma programvaror tex. lägger miljoner filer under samma direktory och då kan närma sig någon begränsning - men också söktiden inom direktoryt börja ta rejäl tid när det är enormt många filer.
Modernare filsystem än NTFS använder olika former av binära sökträn för att minska just söktider inom direktorys på snurrdiskar med enormt många filer i sig och ofta implementerad som en generell lösning för hela filsystemet då det också ingår strategier att lägga ut filerna på en smart sätt för att minimera fragmenteringen och hålla ned armrörelserna vid sökning och läsning på snurrdiskar - något som NTFS _inte_ är känt för... - ni som laddar ned och/eller hostar torrent, bör hitta en annan lösning av lagring som inte involverar NTFS på lagringsmedia, för det är att ta det sämsta av det sämsta när det gäller lagring på mekaniska diskar.
Det finns också andra begränsningar som hur många hårda länkar (dvs olika filnamn som refererar till samma inod och därmed datakropp - vanligt i Unix och används ofta i backupsammanhang för tex. daglig backup av ett filträd för att inte spara samma data flera gånger i filsystemet som separata kopior och ta upp plats, ett typiskt värde brukar vara max 10000 hårdlänkar per fil/inod.
---
slutligen:
Ni som ändå är nyfikna och vill prova att fylla en NTFS-disk med tomma filer och direktorys mha. olika scrip och program.
Gör det på en disk som ni kan partitionera och formatera om efteråt!!.
När man skriver en massa filstruktur i en NTFS-filsystem så är det en midgårdsorm som kallas $MFT som växer över disken (det är denna som lagrar alla filnamn med tillhörande attribut mm. och även mindre mängd data upp till ca 900 Byte per fil läggs direkt efter filnamnet och inte refereras ut till separat lagrings kluster - har man först lagrat säg 512 byte i en fil, stänger filen och sedan öppnar igen lägger till med data på filen så blir det fler sökningar vara första delen alltid måste letas i $MFT och sedan vidare ut över diskens lagringskluster för att plocka ihop filen till en komplett fil igen ) och den har den stora "finessen" att den försvinner inte eller kortas av när man tar bort alla sina filer igen och med den kvar så blir framtida inlagring av filer och data synnerligen ineffektiv när disken börja bli fylld - det är väldigt få och oftast kommersiella defragmenterings-programvaror som kan göra något åt detta, att i praktiken för att få disken snabb igen så är det bättre att formatera hela partitionen med en ny och fräsch NTFS - och det gäller alla NTFS-system som börja bli mer än tolerabelt långsam i sin filhantering och kör man torrent så når man den väggen ganska snabbt på mekaniska diskar - men även SSD påverkas så småningom med fruktansvärt stort antal små och ineffektiva anrop av små block istället för färre och större block i ett svep när det läses och skrivs.