Newsgroup: it.comp.os.linux.iniziare
Titolo: File system per lavorare con molti piccoli file

Ciao a tutti,
Sto facendo delle elaborazioni su un gran numero (> 40000) di file di circa 
300 kb (sono frame da una webcam ripresi a 10 fps), e sto constatando che 
con tutti questi file le operazioni più banali, come ls e rm, sono molto 
lente.
Poiché il tutto è su un disco serial ATA che in altre situazioni si è 
rivelato piuttosto veloce, il mio sospetto è che il problema sia il file 
system ext3, che magari non funziona bene in questa circostanza. 
Secondo voi mettere i file su un file system diverso potrebbe migliorare un 
po' le performance? Che file system mi suggerite per questo scopo?
grazie a tutti
gerlos
-- 
"Solo lo scienziato è vero poeta: ci dà la luna, ci promette le stelle,
 ci farà un nuovo universo se sarà il caso."
                 < 
http://gerlos.altervista.org
 >
 gerlos  +- - - >  gnu/linux registred user #311588

 po' le performance? Che file system mi suggerite per questo scopo?
probabile, ext4 dovrebbe avere prestazioni migliori.
Ciao
Mattia

 po' le performance? Che file system mi suggerite per questo scopo? 
se non ricordo male reiserfs era indicato proprio per questo ma non 
credo sia più mantenuto;
r
-- 
Feltri afferma di essere stato assunto a Il Giornale da *Silvio* Berlusconi.
Non sarebbe il caso che gli italioti si chiedessero se è stata violata 
la legge Mammì?
Un Minuto Per Favore:
Home Page, The Pentangle, I Salon di Baudelaire: 
http://www.umpf.net

 credo sia piï¿œ mantenuto;
penso che per un "pochino" sarï¿œ _occupato_!
ReiserFS goes to chroot jail: Hans gets 15-to-life sentence
-- 
#include <std.disclaimer.h>
Signature automatica inserita a mano.
In God we trust, all others we monitor.(NSA)
Punteggiatura: Nel caso mancasse nel messaggio, aggiungete!!

 Punteggiatura: Nel caso mancasse nel messaggio, aggiungete!!
Appunto, in jail non ha una mazza da fare dalla mattina alla sera,
quindi potrà passare giorno e notte a lavorare su ReiserFS!

 un po' le performance? Che file system mi suggerite per questo scopo?
]zac[
Si e no.
Si perchè extX ha fra i sui punti deboli di avere qualche problema quando
deve gestire una marea di piccoli file.
No perché dovrebbe avere delle funzioni, da specificare in fase di
formattazione della partizione in extX, che dovrebbero attenuare parecchio
quel problema, per esempio da me:
dumpe2fs /dev/sdb7
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          ea904056-d7bc-4f2d-bdd0-1959a6dc8ac2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype
needs_recovery sparse_super large_file
]zac[
P.S. se non ricorso male è la funzione dir_index che consente di avere meno
problemi con molti file di piccole dimensioni.

 meno problemi con molti file di piccole dimensioni.
L'opzione dir_index l'avevo attivata in fase di formattazione, ma 
evidentemente non è abbastanza... :-(
Ora sto ridimensionando il file system, che per fortuna è su un volume LVM, 
e sto creando un nuovo volume, così provo a seguire il consiglio di Rama e 
usare ReiserFS. 
Vista la situazione "insolita" penso che eviterò ext4, preferisco andare sul 
sicuro (di "insicuro" c'è già il mio programma d elaborazione, che richiede 
un sacco di debug...).
ciao e grazie


 Rama e usare ReiserFS.
Ragazzi, sono veramente impressionato: reiserfs è *molto* più veloce di etx3 
con tutti quei file!
Ora posso manipolarli molto più rapidamente! Non mi aspettavo un 
miglioramento di prestazioni così elevato.... :-)
Grazie per la dritta!!!
ciao
gerlos
PS Ma non facciamo che reiserfs possa essere più veloce di etx3 anche per la 
root del mio sistema? Anche là c'è un mucchio di piccoli file (penso a 
/bin/, /etc e simili...). 


 /bin/, /etc e simili...).  
l'usavo per la root, infatti, poi sentito che non veniva più mantenuto 
sono passato a ext3;
mo' mi hai fatto venire la voglia, peccato che abbia reinstallato 
proprio ieri la 12.2;
r
-- 
Abruzzo 2009: dopo 162 giorni consegnati 47 chalet per 200 persone.
Irpinia 1981: dopo 122 giorni consegnati 150 chalet per 450 persone.



Date:   Wed Jun 24 10:03:12 2009 -0700
    Merge branch 'for-linus' of 
git://
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
 
    * 'for-linus' of 
git://
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
: (23 commits)
      switch xfs to generic acl caching helpers
      helpers for acl caching + switch to those
      switch shmem to inode->i_acl
      switch reiserfs to inode->i_acl
      switch reiserfs to usual conventions for caching ACLs
      reiserfs: minimal fix for ACL caching
      switch nilfs2 to inode->i_acl
BTW e' il fs che uso da anni senza problemi, ed e' quello di cui mi fido di 
piu'. L'unica cosa che ho riscontrato e' una certa lentezza nel cancellare 
files di grandi dimensioni (es. > 1 gb).
Ale.

 corretto dire che non viene piu' innovato.  
evvabbé, vuol dire che a breve reinstallo la 12.2, fortunatamente sto 
salvando tutti i pacchetti extra e mo' anche /etc, dovrebbe essere 
questione di pochi minuti;


 /bin/, /etc e simili...).
Un mucchio non è problema nemmeno per extX, una enormità si.
Se cerchi con google trovi dei test che fanno delle misure e consentono di
farsi un'idea con che numero di file, nella STESSA directory, extX comincia
a degradare con le prestazioni, e fanno anche dei paragoni con altri
filesystem.
P.S. Tieni conto che le prestazioni possono essere migliori in una cosa e
peggiori in un altra.

Giuseppe Della Bianca wrote:
Aggiunta:
[root@exnet etc]# ls /bin/ | wc -l
105
[root@exnet etc]# ls /usr/bin/ | wc -l
2933
[root@exnet etc]# ls /usr/lib/ | wc -l
425
[root@exnet etc]# ls /usr/lib64/ | wc -l
2724
[root@exnet etc]# ls /usr/sbin/ | wc -l
414
[root@exnet etc]# ls /sbin/ | wc -l
306

 [root@exnet etc]# ls /bin/ | wc -l
]zac[
E' sbagliato, giusto è ls -l /bin/ | wc -l
Comunque il concetto è controlla, che il numero dei file normalmente
presenti sono di gran lunga inferiori al limite che può dare problemi a
extX .

 Giuseppe Della Bianca wrote:

Capisco. 
Chiaramente una cosa sono 40000 file in una directory (il mio caso iniziale, 
che mandava "in crisi" ext3), e tutt'altra cosa sono 4000 file in /usr/lib o 
in /usr/bin. C'è un ordine di grandezza di differenza.
A questo punto, buon senso suggerirebbe di prendere entrambi i file system 
sullo stesso disco, metterci i dati, e confrontare le performance. 
Se un giorno mi verrà la curiosità di fare questa verifica, sai suggerirmi 
qualche sistema per "misurare" le performance dei file system in modo 
ragionevole?
grazie mille
gerlos


 ragionevole?
]zac[
Dei programmi di test non ho nessuna informazione utile.
Io di solito verifico nelle condizioni reali di utilizzo qual'è il punto più
lento pesante, poi leggo di quel punto i test fatti da altri, faccio
qualche prova ma sempre reale, confronto le informazioni che trovo (per
esempi ci sono vari test sul numero di file e le prestazioni dell'extX, e 
indicano che il calo di prestazioni diventa avvertibile da circa 50000 file
in su).
Il fatto è che i test non possono tenere conto di ogni situazione e provarle
tutte, a meno di non fare dei test che generino pagine su pagine di
risultati.
Tanto per fare un esempio la lentezza del comando ls in teoria potrebbe
essere dovuta anche alla mancanza di memoria ram disponibile per essere
usata come cache del disco, magari perché extX ne usa di più per mantenere
la struttura delle directory.
In sintesi spesso la mia fonte di informazioni iniziale è solo una ricerca
di test di confronto fra i vari filesystem, commenti, prove, e qualche
prova personale.

 prova personale.
Che metrica usi? Vai a spanne o a colpi di "time comando"? ;-)
ciao


 files di grandi dimensioni (es. > 1 gb).
Per quello c'è xfs :)

 Che metrica usi? Vai a spanne o a colpi di "time comando"? ;-)
Nel caso dei test reali la maggior parte delle volte non sono nemmeno
eseguiti lato server, quindi uso orologi, cronometri, ecc. .
Nel caso di test IN programmi/script è molto più comodo automatizzare i test
ed usare funzioni di time/datetime.
Testo nelle condizioni reali perché non raramente capita che una teoria,
magari suffragata da un suite di test, poi porti a risultati scarsi, questo
perché in condizioni reali c'è la concorrenza con altri programmi/consumi
di risorse, e non raramente è preferibile un programma un po' più lento ma
che consumi meno risorse.
Naturalmente è completamente diverso il caso del test di una singola
funzione specifica, in cui si cerca la massima prestazione e basta, ma
anche qui è abbastanza utile confrontare i vari test di cui sono
disponibili i dati.