On Mon, Apr 04, 2011 at 04:22:46PM +0200, Giovanni Orlandi wrote:Secondo me, sinceramente, qui c'e' un problema a valle di come e' strutturato
> Banalmente sono la cancellazione diretta di una directory con milioni di
> files,
> adesso sto lavorando con dischi in RAID di diversi TERA e capita che alcune
> directory si "riempiano" di milioni di FILE
il sistema, una directory con milioni di file secondo me e' un male in se'
e non dovrebbe proprio esistere...
Al di la di ionice che giustamente ti hanno gia' suggerito, c'e' da dire
> poi per cancellare il tutto con il classico "rm -r" occorrono *ALCUNI
> GIORNI *nonostante dei server Dual Xeon che
> vantano 24 processori (12 core * 2 con hypertrading)
> E naturalmente in quel lasso di tempo il server diventa inservibile con
> iostat al 100% sul disco in questione.
che il problema maggiore di usare rm in quel modo e' che e' sequenziale,
lavora su un file alla volta. Parallelizzare l'operazione sicuramente potrebbe
avere notevoli vantaggi e aumentare di molto la velocita' del processo.
Magari un qualcosa lo puoi tirare fuori da qui: http://savannah.gnu.org/projects/parallel/
Poi sicuramente giocando un po' con le opzioni del file system ( sync e simili )
puoi migliorare ancora.
Credo pero' che sia piu' una questione di lentezza di rm per come e' fatto che di fs.
> tout-court di fare incidenti"*
> Certo capisco che sarebbe meglio evitare tout-court di creare directory con
> milioni di file, ma a me questo discorso suona
> come dire *"non mettiamo AirBag sulle auto perché è meglio evitare
No, io direi piuttosto che il paragone giusto e' "evitiamo che in un locale
pubblico dimensionato per 100 persone ne entrino 4000, perche' altrimenti
e' facile che ci scappi il morto".
A questo proposito ritengo che la migliore cosa da fare sia avere un demone e/o
> Una seconda funzione un po' più specifica riguarda la possibilità di fare un
> "du" veloce.
> Per veloce intendo 20 minuti invece di 12 ore.
> Al solito i problemi di performance del "du" sono legati a come i dati sono
> distribuiti sulla partizione.
qualcosa ( e ci sono varie implementazioni sia di demoni che di syscall nei vari os
tra cui linux ) che, all'atto stesso della creazione e/o modifica e/o cancellazione di un file,
creino un indice interrogabile. Quindi non devi piu' calcolare in realtime con il du, ma lo fai
semplicemente interrogando il tuo indice, che viene creato mano a mano che lavori nella directory.
E' sicuramente un approccio con basso impatto durante il normale lavoro delle directory
ma che ti da il risultato non in 20 minuti, ma in pochi secondi o anche meno.
Insomma, secondo me e' l'approccio che e' sbagliato.
--
Franco (nextime) Lanza
Busto Arsizio - Italy
SIP://casa@casa.nexlab.it
NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50
-----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
-----------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk2aOSAACgkQ3+31gNYTLVAxOQCeMwpvFskOQ0/lrsun+mYD9y94
k20AoJAPO/rMjel2Be1v4vroS7OViI6y
=4BGS
-----END PGP SIGNATURE-----