Il sottosistema del disco rappresenta il collo di bottiglia più comune. Il modulo I/O richiede tempi relativamente più lunghi con code più estese, provocando in questo modo un utilizzo del disco elevato e cicli inattivi della CPU. Utilizzare lo strumento iostat durante i carichi di picco previsto per determinare gli indicatori del tempo medio di risposta.
Le operazioni di lettura, scrittura e aggiornamento su disco possono essere sequenziali o casuali. Gli aggiornamenti e le letture casuali rappresentano il modello di accesso più comune nelle installazioni di eDirectory.
Alcune soluzioni per workload casuali:
Aumentare la RAM. Ciò consente di memorizzare nella cache i dati utilizzati frequentemente o i dati a lettura in avanti a livello di file system. Consente inoltre di memorizzare nella cache il DIB all'interno del sottosistema FLAIM.
Utilizzare volumi dedicati per il DIB. Le prestazioni del file system migliorano nei volumi creati in una posizione più vicina all'asse. Utilizzare volumi dedicati per l'RFL e altri log.
In quanto a causa della frammentazione i dischi sviluppano un aumento di latenza in un determinato periodo di tempo, è necessario deframmentarli.
Aggiungere unità disco separate per l'RFL FLAIM. Questo tipo di registrazione può essere eseguita su dischi ad alta velocità.
Utilizzare un ambiente RAID 10 (1+0) con più unità disco.
I file creati da eDirectory possono aumentare fino a 4 GB. I file system ottimizzati per gestire file di grandi dimensioni funzionano in modo efficiente con eDirectory.
Per Solaris™, il file system Veritas* VxFS è un file system basato sull'estensione dove i metadati del file system sono ottimizzati per file di grandi dimensioni. Il file system UFS è indirettamente basato su blocchi, in cui i metadati del file system vengono memorizzati in un numero maggiore di blocchi. UFS può anche essere distribuito per file di grandi dimensioni, ma, in tal caso, il rendimento risulta più lento.
Per Linux™, il file system Reiser è un file system con journaling veloce e offre prestazioni migliori rispetto al file system ext3 su grandi set DIB. Tuttavia, è noto che la modalità di write-back del journaling di ext3 corrisponde alle prestazioni del file system Reiser, sebbene la modalità ordinata di default fornisca una maggiore coerenza dei dati. XFS è un file system con journaling ad alte prestazioni, in grado di gestire file di grandi dimensioni e offrire trasferimenti di dati senza alcun problema. eDirectory 8.8 SP8 è supportato su piattaforme SLES 11 a 32 e 64 bit dotate di file system XFS.
FLAIM supporta una dimensione di blocco di 4 KB e 8 KB. Il valore di default è 4 KB. È lo stesso valore della dimensione di blocco su Linux (tune2fs - l dispositivo). Tuttavia, su Solaris, il file system UFS viene creato con una dimensione di blocco di default pari a 8 KB (df -g punto di montaggio). Se la dimensione di blocco FLAIM è minore rispetto alla dimensioni di blocco del file system, possono verificarsi scritture parziali del blocco. Se la dimensione di blocco del database è maggiore rispetto alla dimensione di blocco del file system, le letture e le scritture singole del blocco vengono suddivise in una serie di operazioni di I/O fisiche distinte. Pertanto, è consigliabile mantenere sempre la dimensione di blocco FLAIM uguale a quella del file system.
Le dimensioni di blocco possono essere controllate solo durante la creazione del DIB. Aggiungere una riga "blocksize=8192" _ndsdb.ini per creare il DIB con dimensione di blocco di 8 KB.
La scelta della dimensione di blocco esatta dipende dalla dimensione media del record FLAIM presente nelle installazioni dell'utente. Sono richieste prove empiriche elaborate sul set appropriato dei dati della prova onde determinare la dimensione di blocco adatta per una specifica installazione.