Ogni file o directory richiede un inode e il nome dell'oggetto risiede in una directory anziché nell'inode stesso. Le comuni operazioni sui metadati, come la creazione, la ricerca, il recupero degli attributi, la ridenominazione, l'enumerazione e l'eliminazione dei file, possono dominare un carico di lavoro con un numero elevato di file anche quando il throughput dei dati è basso. In questi scenari, l'utilizzo della CPU, l'elaborazione seriale delle operazioni e l'RTT di rete possono diventare colli di bottiglia per le prestazioni. Anche il comportamento del protocollo è importante: i client NFS e SMB possono eseguire diverse combinazioni di operazioni di ricerca, apertura, chiusura, recupero degli attributi e lettura delle directory, che spesso dipendono dalla versione del protocollo. Di conseguenza, puoi osservare risultati diversi per flussi di lavoro simili con un numero elevato di file, a seconda del protocollo e della versione del protocollo utilizzati.

ONTAP memorizza gli inode pubblici in un file inode nascosto, gestito dal sistema e a livello di volume. Ogni inode di ONTAP 9 utilizza 288 byte, quindi il file inode stesso consuma capacità utilizzabile nel volume. Un milione di inode pubblici allocati occupa circa 288 MB. L'eliminazione degli oggetti libera gli inode per il riutilizzo, ma il file inode non si riduce.

Inoltre, i file di directory consumano capacità quando un gran numero di nomi viene memorizzato nella stessa directory. Questi file di directory non fanno parte dell'inode file. Memorizzano nomi e mappature ai numeri di inode e maxdir-size limitano ciascuno di essi in modo indipendente. L'impostazione predefinita di 320 MB è un limite massimo, non una riserva; se un file di directory raggiunge i 320 MB di blocchi di file di directory, questi blocchi utilizzano 320 MB di capacità effettiva del volume.

Queste due strutture possono sommarsi. Con un numero elevato di inode allocati, il solo file inode può raggiungere diversi GB e uno o più file di directory di grandi dimensioni possono aggiungere centinaia di megabyte oltre a questo. Un volume può anche avere un file inode di grandi dimensioni con ogni directory ancora di dimensioni ridotte, oppure una directory di grandi dimensioni con un file inode ancora di dimensioni ridotte. Questi metadati consumano capacità utilizzata del volume, un aspetto facile da non notare se guardi solo gli elenchi lato client dei file di dati utente. Il file inode non è un file visibile all'utente; la dimensione del file di directory è visibile sull'oggetto directory stesso.

Le directory di grandi dimensioni richiedono più tempo per essere enumerate rispetto a quelle più piccole e una directory da cui hai eliminato molti file può comunque risultare onerosa da analizzare. La dimensione del file-directory riportata rimane al valore massimo anche dopo l'eliminazione dei nomi. L'hole punching nelle directory indicizzate può recuperare i blocchi fisici vuoti e saltarli durante READDIR, ma normalmente non riduce la dimensione riportata; vedi "Come si comporta il limite maxdir-size" e "Directory sparse e hole punching".

Concentrare milioni di voci in un'unica directory crea un punto di scalabilità e serializzazione a directory singola che può influire sulle prestazioni non solo della directory stessa, ma anche del nodo (o volume) che la possiede. Distribuire i file su una gerarchia multi-directory migliora il parallelismo, riduce l'ambito delle scansioni delle directory e semplifica le attività operative.

Un elevato numero di oggetti può prolungare le scansioni dello spazio dei nomi, la catalogazione dei backup, la replica, l'elaborazione del ripristino e la costruzione dell'indice delle directory dopo il ripristino. Ad esempio, NetApp SnapMirror replica i metadati modificati oltre ai dati dei file, quindi una baseline o un aggiornamento con numerose operazioni di creazione, eliminazione o ridenominazione può risultare oneroso anche quando i file e l'occupazione di capacità sono ridotti. Queste problematiche possono estendersi anche ai backup basati su NDMP.

Per informazioni sul trasferimento dell'indice della directory con SnapMirror, vedi "Indicizzazione delle directory in ONTAP".

maxfiles (configurato come opzione a livello di volume -files) è un limite configurabile per il numero di inode pubblici disponibili in un singolo volume. Questo conteggio include non solo file e directory, ma anche stream denominati, ACL e altri oggetti pubblici, a volte oggetti che non sono visibili in un normale elenco di directory. Il volume contiene un file inode nascosto che memorizza questi record. ONTAP espande il file inode quando è necessario un nuovo inode pubblico e non rimangono record liberi, fino all'impostazione -files e alla dimensione totale del volume. Il valore massimo configurabile per -files dipende dalla dimensione del volume e dai limiti di ONTAP.