Newsgroup: it.comp.os.linux.sys
Titolo: numero massimo file per directory

ciao, sto facendo un robot che scarica delle immagini da diversi siti
internet, attualmente una directory ha 9368 file, mi chiedevo dato che
siamo circa al 10% del lavoro se esiste un limite nel filesystem o se
aumenta organicamente la dimensione degli inode.
ah, si tratta di ext3
grazie
Sat_
-- 
una volta qui era tutto <table>

 organicamente la dimensione degli inode.
No, la dimensione degli i-node e` fissa ed e` 
piuttosto piccola (credo per ext3 sia 128 byte).
Quello che succede in caso di riempimento 
dipende dal filesystem; per esempio ext3 alloca 
blocchi indiretti, doppiamente indiretti e 
triplamente indiretti.
PS questa domanda era da icoli
 

 Sat_
Circa 10^6 senza problemi di performances. Il limite assoluto e' 130x10^15.

 PS questa domanda era da icoli
ops. grazie lo stesso per aver risposto.
ciao

 130x10^15.
direi che sono contento allora.
grazie

 
sì, ho già notato che mi dice "argument list too long" per ora non mi dà
particolari problemi, i riferimenti stanno anche in un database, alla
peggio seleziono da là.
grazie, ciao
Sat-

 sì, ho già notato che mi dice "argument list too long" 
usa xargs per quei lavori li'.

Ipc2 wrote:

sì certo, per ora non mi serve, ma in caso userò senz'altro xargs
ciao

 Circa 10^6 senza problemi di performances
Considerando che per ogni file system ext3 che ho avuto, la sola directory
/usr/bin e` abbastanza per provocare rallentamenti alla scansione della
directory[1], direi che la tua affermazione e` abbastanza forte...
Enrico
[1] ATTENZIONE: il rallentamento vi e` solo E SOLTANTO per la directory
incriminata, e solo E SOLTANTO se viene richiesta una scansione completa
di tale directory (e.g. l'accesso diretto ad un file non crea problemi)

 /usr/bin e` abbastanza per provocare rallentamenti
ls -l | wc -l
3730
Capita solo a te, che posso farci?

 Circa 10^6 senza problemi di performances. Il limite assoluto e' 130x10^15.
Grazie Sig. Spock
:D
-- 
Diesis

 Grazie Sig. Spock
Bones, non si faccia prendere dall'emozione che offusca il ragionamento.

Le limitazioni sono molto "larghe".
In genere non è una buona idea avere una dir con milioni di file, diventa
molto lento ogni operazione fatta sulla dir, dal semplice list(ls)
all'inserimento di un nuovo file(il S.O. deve sapere se esiste o no)
all'apertura del file(sia in R che in W), in pratica ogni operazione che
vada a cercare l'inode associato al file
Software che gestiscono grosse quantità di file fanno uso di una gerarchia
di directory che va a velocizzare(lavorando su piccoli set) le operazioni
sulla directory
Bye,
Raktzo

 directory[1], direi che la tua affermazione e` abbastanza forte...
dir_index
Luca
-- 
Sono un mirabile incrocio tra Tarzan e Giacomo Leopardi.
In me convivono tutte le doti intelluttuali di Tarzan e
tutta la prestanza fisica di Giacomo Leopardi.
A. Borsani

 directory[1], direi che la tua affermazione e` abbastanza forte...
tune2fs(8), dir_index.


 aumenta organicamente la dimensione degli inode.
Occhio che viene creato un numero di "inode possibili" dipendente dalle
dimensioni del disco. Al momento della formattazione ci sono parametri
apposta per decidere il numero di inode disponibili (newsse hai
tantissimi file piccoli, largefile se ne hai pochi e grossi, ecc.).
Con solo 100.000 file non dovresti avere problemi, comunque.
Bye.

Alessandro Pellizzari wrote:

Grazie mille, ora non ricordo la dimensione degli inode che ho dato quando
ho installato slackware (credo quella di default)
quando mi avvicinerò a cifre più significative farò un po' di directory mi
sa. grazie ancora
Sat_



Precisamente:
se V e' il volume in bytes, il numero di inode e'
min{V/2^13, #blocchi}
Il numero minimo di inodes e' V/2^23.

 dipendente dalle dimensioni del disco...
Quindi in teoria il numero massimo di file
_in_tutto_il_disco_ e` pari al numero di i-node.
Solo uno dei tanti limiti di un filesystem.
Ma in pratica cio` che limita il numero di 
file _e'_sempre_ lo spazio sul disco ossia il 
numero di blocchi.
Ed ecco un altro limite ;)