Newsgroup: it.comp.os.linux.sys
Titolo: Lanciare più rm sulla stessa cartella

Ciao a tutti,
 
 
se avessi una cartella molto grande per cui un rm -fR impiegherebbe diversi 
minuti ad essere eseguito e se nel frattempo venisse lanciato nuovamente lo 
stesso comando sulla stessa cartella, cosa succederebbe?
 
 
Ciao e grazie,
  Void


Non dovrebbe succedere niente di particolare
Viene chiamata la system call unlink per ogni file e rmdir sulle 
directory vuote
Poichè gli eventuali errori sono ignorati nessun messaggio di errore 
verrebbe emesso e nessun stop al primo errore
 

 nuovamente lo stesso comando sulla stessa cartella, cosa succederebbe?
 
Durante il periodio della rimozione il tuo mai più moscio sparisce.
Poi trovarlo è un casino.
 
 


Wow, fallico :)
 
P.S.
Anche se è una domanda che sicuramente è stata posta mille volte, 
conviene fare più rm in parallelo in caso di numeri molto elevati di 
file / file enormi / entrambe ?
 
-- 
I fatti mi cosano

 file / file enormi / entrambe ?
 
No. Il secondo rm rallenterebbe tutta l'operazione in quanto
richiederebbe una seconda enumerazione dei files nella directory (se la
dir è grande non ci sta nella cache) che andrebbe ad accodarsi alla coda
dell'IO su disco, aumentando l'IO wait.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left


Adesso magari vienimi anche a dire che premere Stampa! Stampa! Stampa! 
Stampa! Stampa! Stampa! non accende la stampante ...
Che mondo difficile ...
 
Cmq immaginavo una cosa simile
Grazie della conferma


 verrebbe emesso e nessun stop al primo errore
 
Non è vero.
Il kernel, non trovando più il file da rimuovere, scava più a fondo per 
cercarlo e rovina la superficie del disco.
Così con due o più rm contemporanei ti trovi i dischi che sembrano la 
superficie lunare. Di solito non te ne accorgi perchè i blocchi poi vengono 
marcati come danneggiati.
 
E' quindi una operazione assai pericolosa, quasi quanto il quotare male.
 


Come scherzo è bello, il kernel scava piu a fondo e rovina la superficie 
del disco
 
 

 verrebbe emesso e nessun stop al primo errore
 
Grazie, la conferma che cercavo, come anche quella di THe_ZiPMaN: no errori, 
ma più lento.
 
 
Ciao e buona giornata,
  Void


Un' altra soluzione potrebbe essere la tecnica dello split
Piu rm in parallelo ma non sulla stessa directory ma su piu subdirectory 
o files
Oppure tentare invece che con l' opzione -delete di find (se è implementata)
Queste cose sono da provare e misurare la tempistica in quanto le 
performance dipendono a parità di hw da versione del  kernel e fs 
driver, tipo del filesystem,quantità del parallelismo e da rm vs find 
-delete
 
 
 


1) Creiamo 40000 file in 4 alberi da 100 dir ciascuno con 100 file ciascuno.
 
$ time for i in {1..4}
  do
    for j in {1..100}
    do
      mkdir -p provarm/$i/$j
      for k in {1..100}
      do
        touch provarm/$i/$j/$k
      done
    done
  done
 
real	0m55.173s
user	0m10.271s
sys	0m29.059s
 
 
 
2) Svuotiamo la cache di linux, eseguendo da root:
# sync && echo 3 > /proc/sys/vm/drop_caches
 
3) testiamo i tempi del primo comando per 3 volte
$ time rm -r provarm
 
real	0m2.434s
user	0m0.040s
sys	0m0.607s
 
real	0m2.421s
user	0m0.031s
sys	0m0.596s
 
real	0m2.610s
user	0m0.031s
sys	0m0.625s
 
 
Quindi ripetiamo gli step 1 e 2 e misuriamo i tempi degli altri comandi
a rotazione
 
$ time (rm -r provarm/1 & rm -r provarm/2 & rm -r provarm/3 & \
        rm -r provarm/4)
 
real	0m1.141s
user	0m0.014s
sys	0m0.171s
 
real	0m1.149s
user	0m0.008s
sys	0m0.174s
 
real	0m1.209s
user	0m0.011s
sys	0m0.182s
 
 
$ time find provarm/ -delete
 
real	0m2.369s
user	0m0.033s
sys	0m0.503s
 
real	0m2.265s
user	0m0.030s
sys	0m0.511s
 
real	0m2.752s
user	0m0.044s
sys	0m0.482s
 
$ time (rm -r provarm &>/dev/null & rm -r provarm &>/dev/null)
 
real	0m2.923s
user	0m0.136s
sys	0m0.789s
 
real	0m2.669s
user	0m0.245s
sys	0m1.007s
 
real	0m2.578s
user	0m0.228s
sys	0m1.011s
 
 
Chiaramente sono pochi files e quindi i tempi sono ridotti, ma è
comunque significativo notare che il system time dei due rm
contemporanei è circa il doppio del singolo rm; usando un campione più
significativo i risultati si discosterebbero certamente di più



Perfetto, hai messo in pratica quello che non avevo voglia di fare :)
Si spera che questi esempi siano utili per Void
 
 
 

 contemporanei è circa il doppio del singolo rm; usando un campione più
 
... dai tempi riportati a me sembra invece che l'rm in parallelo sulle 
sottocartelle sia effettivamente più veloce, addirittura quasi un quarto 
dell'rm singolo, mentre il find è di poco più veloce dell'rm. Come ci si 
aspettava, infine, l'rm in parallelo sullo stesso percorso è sensibilmente 
più lento, anche se non eccessivamente.
 
Grazie ancora, è stata una prova molto interessante!
 
 
Ciao e buona giornata a tutti,
  Void

Si spera che questi esempi siano utili per Void
 
Peccato per il quoting però...
 
 
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.


 
 
Non sono perfetto
 
 

 dell'rm singolo,
 
  Tu scrivi del rm in parallelo su directory distinte, THe_ZiPMaN invece
dei due rm in parallelo sulla stessa carte^h^h^h^h^hdirectory :-)
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 implementata)
 
Si puo' sempre usare un find con un -exec rm {} \; (se il -delete, che 
tra l'altro non conoscevo come opzione, non e' implementata).
 
Ale


E' vero ma è meno efficiente di una rm -rf per un semplice motivo
l' opzione exec esegue per ogni file elaborato un processo
Per questo non l' ho presa in considerazione
Dai test effettuati da  THe_ZiPMaN la find con -delete sembrerebbe più 
efficiente di una comune rm ricorsiva almeno sul sistema da lui provato
 
 

 efficiente di una comune rm ricorsiva almeno sul sistema da lui provato
 
Sfido io, l'azione ``-delete'' è stata fatta apposta per questi casi.


 
Che non tutti conoscono, per questo l' ho suggerita
 
 
 

 
 
A me risulta che rm -r non faccia un elenco dei file/directory contenuti, 
come invece fanno i file manager grafici.
 
Secondo me la lentezza di due rm -r contemporanei e' dovuta alla meccanica 
del disco rigido, in cui la testina si deve spostare di continuo di 
posizione.
 
E' un po' come fare un cp -r sullo stesso disco invece che di due dischi 
differenti.
 
 
In sintesi non e' una questione di potenza elaborativa ma (circa) solo una 
questione di velocita' dei dischi.

 questione di velocita' dei dischi.
 
Questo ï¿œ quasi certo.


 questione di velocita' dei dischi.
 
 
Ma anche di come è gestito il filesystem.

 tempo/interesse ad approfondire la cosa con perf, ma avrebbe un senso.
]zac[
 
Anche perche' la cosa e' difficile da testare, bisognerebbe provare 
disattivando la cache del disco o facendo in modo che prima di fare i test i 
dati in test siano sempre in cache.