Quanti file posso inserire in una directory?


561

Importa quanti file tengo in una singola directory? In tal caso, quanti file in una directory sono troppi e quali sono gli impatti di avere troppi file? (Questo è su un server Linux.)

Sfondo: ho un sito web di album di foto e ogni immagine caricata viene rinominata in un ID di 8 cifre esadecimali (diciamo, a58f375c.jpg). Questo per evitare conflitti di nomi di file (ad esempio se vengono caricati molti file "IMG0001.JPG"). Il nome file originale e tutti i metadati utili sono memorizzati in un database. In questo momento, ho circa 1500 file nella directory delle immagini. Ciò richiede alcuni secondi per elencare i file nella directory (tramite client FTP o SSH). Ma non riesco a vedere che abbia effetti diversi da quello. In particolare, non sembra esserci alcun impatto sulla velocità con cui un file di immagine viene servito all'utente.

Ho pensato di ridurre il numero di immagini creando 16 sottodirectory: 0-9 e af. Quindi sposterei le immagini nelle sottodirectory in base alla prima cifra esadecimale del nome file. Ma non sono sicuro che ci sia alcun motivo per farlo, tranne per l'elenco occasionale della directory tramite FTP / SSH.

Risposte:


736

FAT32 :

  • Numero massimo di file: 268.173.300
  • Numero massimo di file per directory: 2 16  - 1 (65.535)
  • Dimensione massima del file: 2 GiB - 1 senza LFS , 4 GiB - 1 con

NTFS :

  • Numero massimo di file: 2 32  - da 1 (4,294,967,295)
  • Dimensione massima del file
    • Implementazione: 2 44  - 2 6 byte (16 TiB - 64 KiB)
    • Teorico: 2 64  - 2 6 byte (16 EiB - 64 KiB)
  • Dimensione massima del volume
    • Attuazione: 2 32  - 1 cluster (256 TiB - 64 KiB)
    • Teorici: 2 64  - 1 cluster (1 YiB - 64 KiB)

ext2 :

  • Numero massimo di file: 10 18
  • Numero massimo di file per directory: ~ 1.3 × 10 20 (problemi di prestazioni oltre 10.000)
  • Dimensione massima del file
    • 16 GiB (dimensione del blocco di 1 KiB)
    • 256 GiB (dimensione del blocco di 2 KiB)
    • 2 TiB (dimensione del blocco di 4 KiB)
    • 2 TiB (dimensione del blocco di 8 KiB)
  • Dimensione massima del volume
    • 4 TiB (dimensione del blocco di 1 KiB)
    • 8 TiB (dimensione del blocco di 2 KiB)
    • 16 TiB (dimensione del blocco di 4 KiB)
    • 32 TiB (dimensione del blocco di 8 KiB)

ext3 :

  • Numero massimo di file: min (volumeSize / 2 13 , numberOfBlocks)
  • Dimensione massima del file: uguale a ext2
  • Dimensione massima del volume: uguale a ext2

ext4 :

  • Numero massimo di file: 2 32  - da 1 (4,294,967,295)
  • Numero massimo di file per directory: illimitato
  • Dimensione massima del file: 2 44-1  byte (16 TiB - 1)
  • Dimensione massima del volume: 2 48-1  byte (256 TiB - 1)

24
Presumo che questi siano il numero massimo di file per l'intera partizione, non una directory. Pertanto, queste informazioni non sono troppo utili per quanto riguarda il problema, poiché ci sarebbe un numero uguale di file indipendentemente dal metodo (a meno che non si contino le directory come file).
Strager

19
Dal momento che siamo nel 2012, penso sia giunto il momento di chiarire che ext4 non ha alcun limite relativo al numero di sottodirectory. Anche la dimensione massima del file è cresciuta a 16 TB. Inoltre, la dimensione complessiva del filesystem può essere fino a 1 EB = 1.048.576 TB.
devsnd

7
Apparentemente ext3 ha anche un limite di 60.000 file (o directory o collegamenti) per directory. Ho scoperto la cosa difficile.
pila

8
Vecchia risposta, lo so ... ma quando scrivi EXT4 - Numero massimo di file: 2³² - 1 (4.294.967.295) e Numero massimo di file per directory: illimitato mi hai davvero confuso perché 2³² - 1! = "Illimitato". Immagino di aver bisogno di un caffè ora. ;) Tuttavia +1
e-sushi

11
i limiti del filesystem rigido non rispondono alla domanda "
Importa

191

Ho avuto oltre 8 milioni di file in una singola directory ext3. libc readdir()che viene utilizzato da find, lse la maggior parte degli altri metodi discussi in questo thread nell'elenco grandi directory.

Il motivo lse findsono lenti in questo caso è che readdir()legge solo 32 KB di voci di directory alla volta, quindi su dischi lenti richiederà molte letture per elencare una directory. C'è una soluzione a questo problema di velocità. Ho scritto un articolo abbastanza dettagliato al riguardo: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

La chiave da asporto è: usa getdents()direttamente - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html anziché qualsiasi cosa basata su libc in readdir()modo da poter specificare il buffer dimensione durante la lettura delle voci della directory dal disco.


6
Lettura interessante! Posso chiederti in quale situazione hai avuto 8 milioni di file in una directory? haha
Aᴄʜᴇʀᴏɴғᴀɪʟ

Ho avuto lo stesso. Ho migrato la colonna BLOB di una tabella, ogni colonna BLOB che ho esportato come file. Sono circa 8 milioni di file :)
Spike,

65

Ho una directory con 88.914 file al suo interno. Come te stesso, questo viene utilizzato per la memorizzazione di miniature e su un server Linux.

I file elencati tramite FTP o una funzione php sono lenti sì, ma c'è anche un impatto sulle prestazioni nella visualizzazione del file. ad es. www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg ha un tempo di attesa di 200-400 ms. Come confronto su un altro sito che ho con circa 100 file in una directory l'immagine viene visualizzata dopo solo ~ 40ms di attesa.

Ho dato questa risposta dato che la maggior parte delle persone ha appena scritto come funzioneranno le funzioni di ricerca nella directory, che non userete in una cartella thumb - solo visualizzando staticamente i file, ma saranno interessati alle prestazioni di come i file possono effettivamente essere usati .


6
Questa è l'unica risposta utile. Abbiamo fatto esperienze simili. Il nostro limite è di 1.000 file per ridurre i problemi con i backup (anche troppe directory rallentano).
mgutt

1
Può essere utile montare un disco anche con Noatime : howtoforge.com/… e leggere anche questo: serverfault.com/questions/354017/…
mgutt

2
Quale filesystem stai usando dove rallenta così tanto? XFS, ad esempio, dovrebbe essere in grado di gestire facilmente 100.000 file in una directory senza alcun rallentamento evidente.
Ethan,

1
Contraddicendo l'opinione della maggior parte degli altri, voglio confermare questa risposta. Abbiamo centinaia di migliaia di immagini nel nostro sito Web di social network. Per migliorare le prestazioni siamo stati costretti ad avere 100 (o 1000 per alcuni file) sotto-directory e distribuire i file in esse (ext3 su Linux + Apache per noi).
wmac,

57

Dipende un po 'dal filesystem specifico in uso sul server Linux. Oggi il valore predefinito è ext3 con dir_index, il che rende molto veloce la ricerca di directory di grandi dimensioni.

Quindi la velocità non dovrebbe essere un problema, oltre a quello che hai già notato, che è che le inserzioni impiegheranno più tempo.

Esiste un limite al numero totale di file in una directory. Mi sembra di ricordare che sicuramente funzionerà fino a 32000 file.


4
Gnome e KDE caricano grandi directory a passo di lumache, Windows memorizzerà nella cache la directory in modo ragionevole. Adoro Linux, ma kde e gnome sono scritti male.
torre

1
E ext4 sembra avere l'equivalente di dir_index per impostazione predefinita.
contratto del Prof. Falken è stato violato il

22
Esiste un limite di circa 32 K sottodirectory in una directory in ext3, ma l'OP sta parlando di file di immagine. Non esiste un limite (pratico?) Ai file in un file system ext3 con Dir Index abilitato.
Peter N Lewis,

1
Questa risposta è obsoleta, oggi il valore predefinito è ext4 .
Boris,

1
"Non esiste un limite (pratico?) Ai file in un file system ext3 con Dir Index abilitato" - Ho appena esaurito lo spazio file in una directory su un file system ext4 da 4 TB, con dir_indexabilitato. Avevo circa 17 milioni di file nella directory. La risposta è stata accendere large_dircon tune2fs.
lunixbochs

49

Tieni presente che su Linux se hai una directory con troppi file, la shell potrebbe non essere in grado di espandere i caratteri jolly. Ho questo problema con un album fotografico ospitato su Linux. Memorizza tutte le immagini ridimensionate in un'unica directory. Mentre il file system può gestire molti file, la shell no. Esempio:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

o

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

33
@Steve, utilizzare find (1) e / o xargs (1) per questi casi. Per lo stesso motivo è una buona idea utilizzare tali strumenti negli script anziché nell'espansione della riga di comando.
Dave C,

3
@Steve vedi prestazioni in calo quando aumenta il numero di file in una cartella? O non c'è relazione?
Pacerier

6
Questo è un buon punto, ma a nitpick, la ragione fornita è sbagliata. L' elenco degli argomenti troppo lungo è una limitazione non della shell, ma dell'implementazione del sistema exec. La shell in genere può espandere bene il carattere jolly: è la chiamata a execcon tanti argomenti che restituisce l'errore.
jw013,

Ho avuto lo stesso errore ieri sera (Fedora 15) con "rm" (alcuni file *) con circa 400.000 file in una directory. Sono stato in grado di tagliare i file più vecchi con "trova" al punto da poter "rm" con un carattere jolly.
PJ Brunet,

10.000.000 di file in una directory su etx4 funzionano bene. Non c'è molto di un impatto sulle prestazioni quando si accede. Ma piuttosto lento con il carattere jolly. Fai attenzione quando usi programmi shell a cui piace ordinare i nomi dei file! :)
Simon Rigét,

25

Sto lavorando su un problema simile in questo momento. Abbiamo una struttura di directory gerarchica e usiamo id di immagine come nomi di file. Ad esempio, id=1234567viene inserita un'immagine con

..../45/67/1234567_<...>.jpg

usando le ultime 4 cifre per determinare dove va il file.

Con alcune migliaia di immagini, è possibile utilizzare una gerarchia a un livello. Il nostro amministratore di sistema ha suggerito non più di un paio di migliaia di file in una determinata directory (ext3) per efficienza / backup / qualunque altra ragione avesse in mente.


1
Questa è una soluzione molto carina. Ogni livello della tua directory fino al file dovrebbe contenere al massimo 100 voci se rimani con la suddivisione a 2 cifre, e la maggior parte della directory in basso avrebbe solo 1 file.
RobKohr,


21

Per quello che vale, ho appena creato una directory su un ext4file system con 1.000.000 di file, quindi ho avuto accesso casuale a quei file tramite un server web. Non ho notato alcun premio nell'accedere a questi (diciamo) con solo 10 file lì.

Questo è radicalmente diverso dalla mia esperienza nel farlo ntfsalcuni anni fa.


che tipo di file? testo o immagini? Sono su ext4 e devo importare 80000 immagini in una singola directory sotto wordpress e vorrei sapere se andrà bene
Yvon Huynh

1
@YvonHuynh: il tipo di file è completamente irrilevante. Il sovraccarico nella directory di elencare / tracciare il file è lo stesso indipendentemente.
TJ Crowder,

14

Il problema più grande che ho riscontrato è su un sistema a 32 bit. Una volta superato un certo numero, strumenti come "ls" smettono di funzionare.

Cercare di fare qualsiasi cosa con quella directory una volta superata quella barriera diventa un grosso problema.


9

Ho avuto lo stesso problema. Prova di archiviare milioni di file in un server Ubuntu in ext4. Ho finito con i miei benchmark. Ho scoperto che la directory flat funziona in modo molto migliore pur essendo molto più semplice da usare:

prova delle prestazioni

Ha scritto un articolo .


Un link a una soluzione è il benvenuto, ma assicurati che la tua risposta sia utile senza di essa: aggiungi un contesto attorno al link in modo che i tuoi colleghi utenti abbiano qualche idea di cosa sia e perché sia ​​lì, quindi cita la parte più pertinente della pagina che ' re collegamento a nel caso in cui la pagina di destinazione non sia disponibile. Le risposte che sono poco più di un collegamento possono essere eliminate.
Samuel Liew

1
Interessante. Abbiamo scoperto che dopo persino 10.000 file le prestazioni sono diminuite molto rapidamente fino a diventare inutilizzabili. Abbiamo deciso di suddividere i file in sottodirectory di circa 100 per ogni livello per ottenere prestazioni ottimali. Immagino che la morale della storia sia quella di confrontarla sempre per te sui tuoi sistemi con i tuoi requisiti.
Joshua Pinter,

7

Se il tempo necessario per l'implementazione di uno schema di partizionamento delle directory è minimo, ne sono favorevole. La prima volta che dovrete eseguire il debug di un problema che comporta la manipolazione di una directory di 10000 file tramite la console, capirete.

Ad esempio, F-Spot memorizza i file di foto come AAAA \ MM \ GG \ nomefile.ext, il che significa che la directory più grande con cui ho avuto a che fare durante la manipolazione manuale della mia raccolta di ~ 20000 foto è di circa 800 file. Questo rende anche i file più facilmente sfogliabili da un'applicazione di terze parti. Non dare mai per scontato che il tuo software sia l'unica cosa che accederà ai file del tuo software.


6
Faccio pubblicità contro il partizionamento per data perché le importazioni di massa potrebbero raggruppare i file a una certa data.
massimo

Un buon punto Dovresti assolutamente considerare i tuoi casi d'uso prima di scegliere uno schema di partizionamento. Mi capita di importare foto per molti giorni in una distribuzione relativamente ampia, E quando voglio manipolare le foto al di fuori della data di F-Spot è il modo più semplice per trovarle, quindi per me è una doppia vittoria.
Sparr,

7

Dipende assolutamente dal filesystem. Molti file system moderni usano strutture di dati decenti per archiviare il contenuto delle directory, ma i file system più vecchi spesso aggiungono semplicemente le voci a un elenco, quindi il recupero di un file è un'operazione O (n).

Anche se il filesystem lo fa correttamente, è comunque assolutamente possibile che i programmi che elencano i contenuti della directory rovinino e facciano un ordinamento O (n ^ 2), quindi per essere al sicuro limiterei sempre il numero di file per directory a non più di 500.


7

Dipende molto dal filesystem utilizzato e anche da alcuni flag.

Ad esempio, ext3 può avere molte migliaia di file; ma dopo un paio di migliaia, era molto lento. Principalmente quando si elenca una directory, ma anche quando si apre un singolo file. Alcuni anni fa, ha ottenuto l'opzione 'htree', che ha ridotto drasticamente il tempo necessario per ottenere un inode dato un nome file.

Personalmente, utilizzo le sottodirectory per mantenere la maggior parte dei livelli al di sotto di un migliaio di elementi. Nel tuo caso, creerei 256 directory, con le ultime due cifre esadecimali dell'ID. Utilizzare le ultime e non le prime cifre, in modo da ottenere un bilanciamento del carico.


6
Se i nomi dei file fossero completamente casuali, non importerebbe quali cifre sono state utilizzate.
Strager

In effetti, questi nomi di file vengono generati casualmente.
Kip

2
Oppure usa i primi N byte del digest SHA-1 del nome file.
gawi

6

ext3 ha infatti limiti di dimensione della directory e dipendono dalla dimensione del blocco del filesystem. Non esiste un "numero massimo" di file per directory, ma un "numero massimo di blocchi per directory utilizzato per memorizzare le voci di file". In particolare, la dimensione della directory stessa non può crescere oltre un b-tree di altezza 3 e la dissolvenza dell'albero dipende dalla dimensione del blocco. Vedi questo link per alcuni dettagli.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

Sono stato morso recentemente da questo su un filesystem formattato con blocchi 2K, che inspiegabilmente stava ricevendo messaggi del kernel pieni di directory warning: ext3_dx_add_entry: Directory index full!quando stavo copiando da un altro filesystem ext3. Nel mio caso, una directory con solo 480.000 file non è stata copiata nella destinazione.


5

La domanda si riduce a cosa farai con i file.

Sotto Windows, qualsiasi directory con più di 2k file tende ad aprirsi lentamente per me in Explorer. Se sono tutti file di immagine, più di 1k tende ad aprirsi molto lentamente nella visualizzazione miniature.

Un tempo, il limite imposto dal sistema era di 32.767. Ora è più alto, ma anche quello è troppi file da gestire contemporaneamente nella maggior parte dei casi.


5

Ciò che la maggior parte delle risposte sopra non riesce a mostrare è che non esiste una risposta "taglia unica per tutti" alla domanda originale.

Nell'ambiente di oggi abbiamo un grande conglomerato di hardware e software diversi: alcuni a 32 bit, altri a 64 bit, altri all'avanguardia e altri collaudati, affidabili e mai in evoluzione. A ciò si aggiunge una varietà di hardware più vecchi e più recenti, sistemi operativi più vecchi e più recenti, diversi fornitori (Windows, Unix, Apple, ecc.) E una miriade di utility e server che si susseguono. Poiché l'hardware è migliorato e il software è stato convertito in compatibilità a 64 bit, c'è stato necessariamente un considerevole ritardo nel far sì che tutti i pezzi di questo mondo così vasto e complesso giochino bene con il rapido ritmo dei cambiamenti.

IMHO non esiste un modo per risolvere un problema. La soluzione è quella di ricercare le possibilità e poi, per tentativi ed errori, trovare ciò che funziona meglio per le tue esigenze particolari. Ogni utente deve determinare ciò che funziona per il proprio sistema anziché utilizzare un approccio di cookie cutter.

Ad esempio, ho un media server con pochi file molto grandi. Il risultato sono solo circa 400 file che riempiono un'unità da 3 TB. Viene utilizzato solo l'1% degli inode, ma viene utilizzato il 95% dello spazio totale. Qualcun altro, con molti file più piccoli, potrebbe esaurire gli inode prima che si avvicinino per riempire lo spazio. (Sui filesystem ext4 come regola generale, 1 inode viene utilizzato per ogni file / directory.) Mentre teoricamente il numero totale di file che possono essere contenuti in una directory è quasi infinito, la praticità determina che l'utilizzo complessivo determina unità realistiche, non solo capacità del filesystem.

Spero che tutte le diverse risposte di cui sopra abbiano promosso il pensiero e la risoluzione dei problemi piuttosto che presentare una barriera insormontabile al progresso.


4

Ricordo di aver eseguito un programma che stava creando un'enorme quantità di file in uscita. I file sono stati ordinati a 30000 per directory. Non ricordo di aver avuto problemi di lettura quando ho dovuto riutilizzare l'output prodotto. Era su un laptop Ubuntu Linux a 32 bit e persino Nautilus mostrava i contenuti della directory, anche se dopo pochi secondi.

filesystem ext3: codice simile su un sistema a 64 bit gestiva bene 64000 file per directory.


4

"Dipende dal filesystem"
Alcuni utenti hanno affermato che l'impatto sulle prestazioni dipende dal filesystem utilizzato. Ovviamente. I filesystem come EXT3 possono essere molto lenti. Ma anche se usi EXT4 o XFS non puoi impedire che elencare una cartella attraverso lso findo attraverso una connessione esterna come FTP diventerà più lento e più lento.

Soluzione
Preferisco allo stesso modo di @armandino . Per questo uso questa piccola funzione in PHP per convertire gli ID in un percorso file che risulta in 1000 file per directory:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

oppure potresti usare la seconda versione se vuoi usare caratteri alfanumerici:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

i risultati:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Come puoi vedere per la $intversione, ogni cartella contiene fino a 1000 file e fino a 99 directory contenenti 1000 file e 99 directory ...

Ma non dimenticare che molte directory causano gli stessi problemi di prestazioni!

Infine, dovresti pensare a come ridurre la quantità di file in totale. A seconda del tuo obiettivo puoi utilizzare gli sprite CSS per combinare più piccole immagini come avatar, icone, faccine, ecc. O se usi molti piccoli file non multimediali, considera la possibilità di combinarli, ad esempio in formato JSON. Nel mio caso avevo migliaia di mini-cache e alla fine ho deciso di combinarle in pacchetti da 10.


3

Rispetto che questo non risponde totalmente alla tua domanda su quanti siano troppi, ma un'idea per risolvere il problema a lungo termine è che oltre a memorizzare i metadati del file originale, memorizza anche la cartella su disco in cui è memorizzata - normalizza fuori quel pezzo di metadati. Una volta che una cartella supera un certo limite con cui ti senti a tuo agio per prestazioni, estetica o qualsiasi motivo, devi solo creare una seconda cartella e iniziare a rilasciare i file lì ...


3

Ho riscontrato un problema simile. Stavo cercando di accedere a una directory con oltre 10.000 file al suo interno. Stava impiegando troppo tempo a creare l'elenco dei file ed eseguire qualsiasi tipo di comando su uno qualsiasi dei file.

Ho pensato a un piccolo script php per farlo da solo e ho cercato di trovare un modo per impedirlo dal timeout nel browser.

Quello che segue è lo script php che ho scritto per risolvere il problema.

Elenco dei file in una directory con troppi file per FTP

Come aiuta qualcuno


1

Non una risposta, ma solo alcuni suggerimenti.

Selezionare un FS (file system) più adatto. Da un punto di vista storico, tutti i tuoi problemi sono stati abbastanza saggi da essere una volta centrale per gli FS che si sono evoluti nel corso di decenni. Voglio dire, FS più moderno supporta meglio i tuoi problemi. Prima fai una tabella di decisione comparativa basata sul tuo scopo ultimo dall'elenco FS .

Penso che sia tempo di spostare i tuoi paradigmi. Quindi suggerisco personalmente di utilizzare un sistema FS consapevole del sistema distribuito , il che significa che non ci sono limiti per quanto riguarda dimensioni, numero di file e così via. Altrimenti, prima o poi sarai sfidato da nuovi problemi imprevisti.

Non sono sicuro di lavorare, ma se non menzioni alcuni esperimenti, prova AUFS sul tuo file system attuale. Immagino che abbia funzionalità per imitare più cartelle come un'unica cartella virtuale.

Per superare i limiti hardware è possibile utilizzare RAID-0.


1

Non esiste un'unica cifra "troppa", purché non superi i limiti del sistema operativo. Tuttavia, più file in una directory, indipendentemente dal sistema operativo, maggiore è il tempo necessario per accedere a qualsiasi singolo file e, sulla maggior parte dei sistemi operativi, le prestazioni non sono lineari, quindi per trovare un file su 10.000 ci vuole più di 10 volte di più quindi per trovare un file tra 1.000.

I problemi secondari associati alla presenza di molti file in una directory includono errori di espansione con caratteri jolly. Per ridurre i rischi, potresti prendere in considerazione l'ordine di ordinare le tue directory per data di caricamento o altri utili metadati.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.