Supponi di iniziare con una tabula rasa, cioè non hai affatto avuto accesso al filesystem. Ora dite di eseguire stat ("/ some / dir / file"). Innanzitutto il kernel deve trovare il file, che in termini tecnici è chiamato inode. Inizia guardando nel superblocco del filesystem, che memorizza l'inode della directory root. Quindi apre la directory root, trova "some", apre quella, trova "dir", ecc. Alla fine trova l'inode per il file.
Quindi devi effettivamente leggere i dati dell'inode. Dopo la prima lettura questo è anche memorizzato nella cache nella RAM. Quindi, una lettura deve avvenire solo una volta.
Pensa all'HD come a un vecchio giradischi, una volta che sei nel posto giusto con l'ago puoi continuare a leggere le cose velocemente mentre ruota. Tuttavia, una volta che hai bisogno di trasferirti in un posto diverso, chiamato "cercare" stai facendo qualcosa di molto diverso. È necessario spostare fisicamente il braccio, quindi attendere che il piatto ruoti fino a quando il punto giusto si trova sotto l'ago. Questo tipo di movimento fisico è intrinsecamente lento, quindi i tempi di ricerca dei dischi sono piuttosto lunghi.
Quindi, quando cerchiamo? Dipende ovviamente dal layout del filesystem. I filesystem cercano di archiviare i file consecutivamente per aumentare le prestazioni di lettura e generalmente cercano anche di archiviare gli inode per una singola directory vicini l'uno all'altro, ma tutto dipende da cose come quando i file vengono scritti, frammentazione del filesystem, ecc. Quindi, nel peggiore dei casi caso, ogni stat di un file provocherà una ricerca e quindi ogni apertura del file provocherà una seconda ricerca. Quindi, ecco perché le cose impiegano così tanto tempo quando nulla viene memorizzato nella cache.
Alcuni filesystem sono migliori di altri, la deframmentazione potrebbe aiutare. Puoi fare alcune cose nelle app. Ad esempio, GIO ordina gli inode ricevuti da readdir () prima di dichiararli sperando che il numero di inode abbia una sorta di relazione con l'ordine del disco (generalmente ha) minimizzando così le ricerche casuali avanti e indietro.
Una cosa importante è progettare l'archiviazione dei dati e le app per ridurre al minimo la ricerca. Ad esempio, questo è il motivo per cui la lettura / usr / bin di Nautilus è lenta, poiché i file in essa contenuti in genere non hanno estensione, per ciascuno di essi è necessario eseguire uno sniffing magico. Quindi, dobbiamo aprire ogni file => una ricerca per file => slooooow. Un altro esempio sono le app che memorizzano informazioni in molti piccoli file, come una volta gconf, una cattiva idea. Ad ogni modo, in pratica non credo che ci sia molto da fare se non provare a nascondere le latenze.