Domanda

Se ci sono circa 1.000.000 di singoli file (per lo più 100k di dimensioni) in una singola directory, in modo chiaro (non ci sono altre directory e file in essi), ci saranno compromessi in termini di efficienza o svantaggi in altri modi possibili?

È stato utile?

Soluzione

ARG_MAX metterà in discussione questo ... per esempio, rm -rf * (mentre si trova nella directory) dirà "troppi argomenti". Le utility che vogliono fare una sorta di globbing (o una shell) avranno delle interruzioni di funzionalità.

Se quella directory è disponibile al pubblico (diciamo via ftp o web server) potresti riscontrare ulteriori problemi.

L'effetto su un determinato file system dipende interamente da quel file system. Con quale frequenza si accede a questi file, qual è il file system? Ricorda che Linux (per impostazione predefinita) preferisce tenere in memoria i file a cui hai avuto accesso di recente mentre si scambiano i processi, a seconda delle impostazioni. Questa directory è servita tramite http? Google lo vedrà e lo indicherà? In tal caso, potrebbe essere necessario regolare la pressione della cache VFS e lo swappiness.

Modifica

ARG_MAX è un limite di sistema per quanti argomenti possono essere presentati al punto di ingresso di un programma. Quindi, prendiamo 'rm', e l'esempio " rm -rf * " - la shell trasformerà '*' in un elenco di file delimitato da spazi che a sua volta diventa l'argomento di 'rm'.

La stessa cosa accadrà con ls e molti altri strumenti. Ad esempio, ls foo * potrebbe interrompersi se troppi file iniziano con 'foo'.

Consiglio (non importa quale fs sia in uso) di suddividerlo in blocchi di directory più piccoli, solo per questo motivo.

Altri suggerimenti

La mia esperienza con directory di grandi dimensioni su ext3 e dir_index abilitate:

  • Se conosci il nome del file a cui vuoi accedere, non c'è quasi nessuna penalità
  • Se si desidera eseguire operazioni che devono essere lette nell'intera voce della directory (come un semplice ls su quella directory), saranno necessari diversi minuti per la prima volta. Quindi la directory rimarrà nella cache del kernel e non ci sarà più alcuna penalità
  • Se il numero di file diventa troppo elevato, si verificano problemi ARG_MAX e altri. Ciò significa sostanzialmente che il carattere jolly ( * ) non funziona sempre più come previsto. Questo è solo se vuoi davvero eseguire un'operazione su tutti i file contemporaneamente

Senza dir_index , tuttavia, sei davvero fregato :-D

La maggior parte delle distro usa Ext3 per impostazione predefinita, che può utilizzare l'indicizzazione b-tree per directory di grandi dimensioni . Alcune distribuzioni hanno questa funzione dir_index abilitata per impostazione predefinita in altre dovresti abilitarla da solo. Se lo abiliti, non c'è rallentamento nemmeno per milioni di file.

Per vedere se la funzione dir_index è attivata, fare (come root):

tune2fs -l /dev/sdaX | grep features

Per attivare la funzione dir_index (come root):

tune2fs -O dir_index /dev/sdaX
e2fsck  -D /dev/sdaX

Sostituisci / dev / sdaX con la partizione per la quale vuoi attivarlo.

Quando esegui accidentalmente "ls" in quella directory, oppure usa il completamento della scheda, o vuoi eseguire " rm * " ;, avrai un grosso problema. Inoltre, potrebbero verificarsi problemi di prestazioni a seconda del file system.

È buona norma raggruppare i file in directory denominate dai primi 2 o 3 caratteri dei nomi dei file, ad esempio

aaa/
   aaavnj78t93ufjw4390
   aaavoj78trewrwrwrwenjk983
   aaaz84390842092njk423
   ...
abc/
   abckhr89032423
   abcnjjkth29085242nw
   ...
...

La risposta ovvia è che la cartella sarà estremamente difficile da usare per gli umani molto prima di qualsiasi limite tecnico, (tempo impiegato per leggere l'output di ls per uno, sono dozzine di altri motivi) C'è una buona ragione per cui puoi diviso in sottocartelle?

Non tutti i filesystem supportano così tanti file.

Su alcuni di essi (ext2, ext3, ext4) è molto facile raggiungere il limite dell'inode.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top