60000 non è niente, anche 20000. Ma dovresti raggruppare questi 20000 con qualsiasi mezzo per velocizzare l'accesso ad essi. Magari in gruppi di 100 o 1000, prendendo il numero della directory e dividendolo per 100, 500, 1000, qualunque cosa.
Ad esempio, ho un progetto in cui i file hanno numeri. Li raggruppo in 1000, quindi ho
id/1/1332
id/3/3256
id/12/12334
id/350/350934
In realtà potresti avere un limite rigido:alcuni sistemi hanno inode a 32 bit, quindi sei limitato a un numero di 2^32 per file system.
Se il filesystem del tuo server ha dir_index funzione attivata (vedi tune2fs(8) per i dettagli sul controllo e l'attivazione della funzione), è possibile archiviare ragionevolmente fino a 100.000 file in una directory prima che le prestazioni si riducano. (dir_index è stato l'impostazione predefinita per i nuovi filesystem per la maggior parte delle distribuzioni ormai da diversi anni, quindi sarebbe solo un vecchio filesystem che non ha la funzione attiva per impostazione predefinita.)
Detto questo, l'aggiunta di un altro livello di directory per ridurre il numero di file in una directory di un fattore 16 o 256 aumenterebbe drasticamente le possibilità di cose come ls * funziona senza sovraccaricare il massimo argv del kernel taglia.
Tipicamente, questo è fatto da qualcosa come:
/a/a1111
/a/a1112
...
/b/b1111
...
/c/c6565
...
cioè, anteponendo una lettera o una cifra al percorso, in base a qualche caratteristica che puoi calcolare dal nome. (I primi due caratteri di md5sum o sha1sum del nome del file è un approccio comune, ma se hai ID oggetto univoci, allora 'a'+ id % 16 è un meccanismo abbastanza semplice per determinare quale directory usare.)
ext[234] i filesystem hanno un numero massimo fisso di inode; ogni file o directory richiede un inode. Puoi vedere il conteggio e i limiti correnti con df -i . Ad esempio, su un filesystem ext3 da 15 GB, creato con le impostazioni predefinite:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda 1933312 134815 1798497 7% /
Non c'è limite alle directory in particolare oltre a questo; tieni presente che ogni file o directory richiede almeno un blocco del filesystem (in genere 4 KB), anche se si tratta di una directory con un solo elemento al suo interno.
Come puoi vedere, tuttavia, è improbabile che 80.000 inode siano un problema. E con il dir_index opzione (abilita con tune2fs ), le ricerche in directory di grandi dimensioni non sono un grosso problema. Tuttavia, tieni presente che molti strumenti amministrativi (come ls o rm ) può avere difficoltà a gestire le directory con troppi file al loro interno. Pertanto, si consiglia di suddividere i file in modo da non avere più di poche centinaia o mille elementi in una determinata directory. Un modo semplice per farlo è eseguire l'hashing di qualunque ID tu stia utilizzando e utilizzare le prime cifre esadecimali come directory intermedie.
Ad esempio, supponiamo che tu abbia l'ID articolo 12345 e l'hash a 'DEADBEEF02842.......' . Potresti archiviare i tuoi file in /storage/root/d/e/12345 . Ora hai ridotto di 1/256 il numero di file in ogni directory.