[BASH] Tracciare intervallo di esecuzione processo lento

[DoctorStrange]

Buonasera a tutti,

Come di solito accade, a causa della mia modesta conoscenza di bash ho problemi nella realizzazione di script apparentemente banali.

I presupposti sono questi: Ho una cartella della quale vorrei fare un backup sulla pen drive se clicco sul pulsante di un lanciatore che ho realizzato.

La parte inerente il lanciatore funziona regolarmente.

La cartella è composta da una grande quantità di files, ma ognuno di questi è di una dimensione modesta, tipicamente 10 kB.

Il problema è che l'intera sequenza di backup, che nel dettaglio è così composta: entro nella pen Drive tramite una comunissima "Change Directory", e cerco se esiste una versione precedente della cartella, il cui nome non cambia mai e, se esiste, la elimina per intero.

Torno poi nel percorso dove si trova la cartella da copiare, qui dò il comando di copia ma, questo comando impiega un intervallo di tempo insolitamente lungo per copiare questi files, dunque la domanda: Esiste un modo per tracciare quale processo impiega più temo del dovuto?

Sessanta secondi mi sembrano troppi per copiare questi files:

Codice: Seleziona tutto

totale 212K
drwxr-xr-x 3 leonardo leonardo 4,0K mag  9 19:11 .
drwxrwxrwx 3 leonardo leonardo 4,0K mag  5 18:56 ..
-rwxr-xr-x 1 leonardo leonardo 1,6K mag  6 15:15 Assembla.sh
-rw-r--r-- 1 leonardo leonardo  272 mag  3 09:58 Cose da fare
drwxr-xr-x 8 leonardo leonardo 4,0K mag  8 20:42 .git
-rw-r--r-- 1 leonardo leonardo  105 mag  2 15:14 .gitignore
-rwxrwxrwx 1 leonardo leonardo  176 mag  6 14:59 LinkerScript.ld
-rwxrwxrwx 1 leonardo leonardo  14K mag  8 20:42 main2.s
-rw-r--r-- 1 leonardo leonardo  16K mag  9 19:11 .main2.s.swp
-rwxrwxrwx 1 leonardo leonardo 2,4K mag  9 19:11 Makefile
-rwxrwxrwx 1 leonardo leonardo  420 mag  9 18:49 RimuoviAssemblati.sh
-rwxr-xr-x 1 leonardo leonardo  64K mag  3 14:25 SequenzaInizializzazione_backup.s
-rwxrwxrwx 1 leonardo leonardo  64K mag  4 19:05 SequenzaInizializzazione.s
-rwxr-xr-x 1 leonardo leonardo  14K mag  3 11:26 Spiegazione linker e sequenza di avvio

Questo invece è lo script nella sua attuale versione.

Codice: Seleziona tutto

#!/bin/bash

if [ -d /media/leonardo/MICRODRIVE ]; then

if [ -f /media/leonardo/MICRODRIVE/stm32-assembly-repository ]; then
rm -R /media/leonardo/MICRODRIVE/stm32-assembly-repository;
fi;

cp -R /home/leonardo/MioArchivio/CortexBuildDir/Sorgenti/BitBucketSTM32-Sources/stm32-assembly-repository /media/leonardo/MICRODRIVE;

if [ $? ]; then
notify-send 'Copia completata' 'Copia sorgenti Stm32 completata correttamente su Microdrive';
fi

else
notify-send 'Attenzione' 'Pen drive non inserita'
fi

Questi i dettagli del mount della mia pen drive:

Codice: Seleziona tutto

/dev/sdb1 /media/leonardo/MICRODRIVE vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro 0 0

Grazie mille a tutti e buona serata

[giorgiofoga]

c'è una ragione particolare per cui usi i comandi bash? .... te lo chiedo solo perchè non sono un guru neppure io in bash .... così ho imparato a utilizzare script bash all'interno di programmi in c++ ... molto meglio direi.
Per le performances.... da quel che ricordo con le usb pen anche io ho avuto tempi di risposta lunghi, non ostante gli ottimi settaggi .... diciamo comunque che 60 sec potrebbero essere il tempo totale dall'inserimento della pen drive al lavoro ultimato.... per darti un'idea dei tempi.

saluti
gfx

[rai]

A meno che la maggior parte dei file vengano modoficati tra un backup e l'altro, usare rsync invece di cp dovrebbe accelerare il backup anche di molto

[giorgiofoga]

@rai infatti è proprio per questo che ho chiesto se usare bash fosse indispensabile ..... in ogni caso è possibile usare inotifywait....

Codice: Seleziona tutto

#!/bin/sh
while inotifywait -e modify /var/log/messages; do
  if tail -n1 /var/log/messages | grep apache; then
    kdialog --msgbox "Blah blah Apache"
  fi
done

per controllare velocemente se la cartella è modificata e scegliere poi lo strumento più opportuno...

gfx

[DoctorStrange]

Prima di tutto grazie mille ad entrambi.

Per giorgiofoga:

Non capisco quale sia lo scopo di usare il C. In pratica dovrei realizzare una funzione C che mi interroghi un comando bash, e poi tornare al C per visualizzare l'esito? A questo punto realizzo tutto nativamente in bash.

Per rai:

Ottima idea, provo subito a sostituire il "cp" con un rsync e vedo se avrò un miglioramento, ma questo mi sembra più un modo aggirare il problema, del quale non ne capisco la causa.

Al momento per darvi un idea dei tempi di cui si parla ho provato ad eseguire lo stesso script, anteponendo il comando "time", e questo è il responso:

Codice: Seleziona tutto

real    0m52.992s
user   0m0.040s
sys      0m1.436s

Quindi impiega quasi un minuto per copiare quei files, e mi sembra esagerato.

Detto questo ho pensato: C'è un file all'interno di quella cartella che l'ho protetto assegnandoli privilegi di immutabilità (con chattr), potrebbe essere questo il motivo che rallenta così tanto la copia? Magari l'attributo di immutabilità, impedisce anche la copia, e quindi il sistema impiega molto tempo e poi salta quell'unico file, possibile?

[giorgiofoga]

@harpefalcata .... non esattamente dovresti dare un programma in c che fa tutto .... il mio discorso (usare entrambe) diventa valido se inserici il tutto in un'applicazione che fa molto altro .... in questo modo dividi i compiti: bash gestione file, cc+ gestione sistema, c gestione processi rapidi e semplici (calcoli o altro di simile) ....

dai file e permessi che hai elencato non è che veda chissà che problemi.

uso ubuntu in ambito industriale e nel tempo ho notato che:
1 non tutti i pc (inteso stesso modello) hanno uguali tempi di scrittura e lettura sulle medesime porte (immagino a causa di problemi legati allinstallazione del SO e a difetti vari di fabbrica)
2 le usb pen hanno, come tutti i dispositivi di memoria, dei tempi propri diversi da produttore e da modello a modello ... in oltre i contatti della porta stessa o della penna inficiano la velocità
3 spesso una porta + pen drive che fino a ieri andavano ad una certa velocità oggi la dimezzano ....
4 in questo momento ho 3 pen drive sulla scrivania tutte stessa marca e modello, provo a copiare tramite medesima porta usb lo stesso file su tutte e tre .... 3 tempi diversi ... su una quasi doppi rispetto a quella più nuova.
5 hai provato ad usare nutilus per eseguire la copia e verificare i tempi?
è vero che tu non hai neanche 1Mb da copiare e la cosa dovrebbe essere istantanea ...

ls -dl /tuachiavetta ..... trovi questi permessi?
drwxrwxrwx oppure questi drwxr-xr-x

la mia cartella di test archivio invece ha questi permessi:
drwxrwxr-x

se provo ad utilizzare il tuo script .... in qualche centesimo di secondo copio di file da cartella home/stm32-assembly-repository a /media/miaUSBPEN/stm32-assembly-repository i file copiati sono 258Kb.

non ho provato con un lanciatore ... ma da terminale .... se usi un lanciatore con icona e qualche sorta di waiting messages dovrai aspettarti dei tempi un pò più lunghi.

gfx

[rai]

La cartella è composta da una grande quantità di files, ma ognuno di questi è di una dimensione modesta, tipicamente 10 kB.

a parità di dati da scrivere, più numerosi sono i file più lento è il processo dato che per ciascuno bisogna scrivere anche sulla tabella di allocazione.
Naturalmente questo discorso incide poco se nel tuo caso i file sono _soltanto_ quelli che hai elencato (e che io avevo preso solo per un esempio)

Ottima idea, provo subito a sostituire il "cp" con un rsync

ovviamente rsync elimina ogni senso alla verifica dell'esistenza della cartella e alla sua eventuale cancellazione (la cui utilità a dire il vero non mi è chiara nemmeno usando cp)

@rai infatti è proprio per questo che ho chiesto se usare bash fosse indispensabile ..... in ogni caso è possibile usare inotifywait....

Codice: Seleziona tutto

    #!/bin/sh
    while inotifywait -e modify /var/log/messages; do
      if tail -n1 /var/log/messages | grep apache; then
        kdialog --msgbox "Blah blah Apache"
      fi
    done

per controllare velocemente se la cartella è modificata e scegliere poi lo strumento più opportuno...

gfx

Si ma dato che esistono dei tool ottimizzati per fare una certa cosa (in questo caso direi rsync) non è efficiente ri-progettare la ruota con *sh per fare la stessa cosa. Ciò non toglie che uno possa farlo per le ragioni più diverse (mi capita di farlo) ma sapendo che c'è una soluzione migliore .

[crap0101]

aggiungo solo che

Codice: Seleziona tutto

cp -R /home/leonardo/MioArchivio/CortexBuildDir/Sorgenti/BitBucketSTM32-Sources/stm32-assembly-repository /media/leonardo/MICRODRIVE;

if [ $? ]; then
notify-send 'Copia completata' 'Copia sorgenti Stm32 completata correttamente su Microdrive';
fi

fa l'esatto contrario di quello che sembri volere: se $? è diverso da zero (per cui cp è terminato con errore) mandi il messaggio "copia completata", dovresti dovuto usare

Codice: Seleziona tutto

if [ $? -eq 0 ];

oppure

Codice: Seleziona tutto

if cp comando; then ...

[giorgiofoga]

Ovviamente rai ha ragione ... ripeto che non sono un conoscitore di bash ... ciò non ostante il codice di harpefalcata copia i file come vorrebbe fare .... anche se poi lancia i messaggi sbagliati come dice crap0101 .... di sicuro però non è quello che voleva ottenere harpefalcata poichè se è vero che il messaggi è errato (non ho controllato a dire la verità che effettivamente la copia abbia un errore, ma sopratutto di che tipo) è pur vero che i miei file sono stati copiati perfettamente ed essi di per sè non contengono errori .... ciò non significa che l'operazione si possa concludere in modo errato egualmente e soprattutto che l'errore commesso sia più o meno influente nel sistema.

Ho aggiunto questo per confermare che il codice di per sè compie le azioni di copia e cancellazione .... e che quindi harpefalcata può rivolgere il suo interesse verso altri tipi di problemi.

saluti
gfx

[DoctorStrange]

Il fatto che copia è certo, il dubbio ed il motivo dell'intero thread, è chiedere per quale motivo impiega tutto questo tempo, a prescindere dai messaggi che, in ogni caso sono corretti.

Infatti, a condizione che la pen drive sia inserita nel sistema e correttamente riconosciuta, come accade di solito, una volta che la sequenza di copia è completa, il messaggio compare senza errori.

Io non conosco precisamente quale sia l'exit status di cp, se con lo zero identifichi successo o fallimento ma, considerato il fatto che al momento il messaggio mi compare proprio in seguito alla copia correttamente eseguita, sono ragionevolmente certo che la sintassi del cp sia corretta.

I prossimi test che farò, saranno di eliminare le cartelle git dalla directory, e rimuovere i permessi di immutabilità dal file, e vedere se la soluzione migliora cercando così di circoscrivere il problema, ma ultimamente a lavoro ho scadenze imminenti.

Vi farò sapere.

Saluti

[rai]

. . . a prescindere dai messaggi che, in ogni caso sono corretti.

No i messaggi _non_ sono corretti nel senso che col modo che usi non vedrai mai un messaggio di errore dato che dalla doc di cp si legge

An exit status of zero indicates success, and a nonzero value indicates failure.

che in effetti è quello che uno si aspetterebbe.
E quindi con qualsiasi esito della copia il tuo script ti dirà sempre di stare tranquillo

Codice: Seleziona tutto

~$ if [ 0 ] ; then echo "OK"; else echo "KO";fi
OK
~$ if [ 113 ] ; then echo "OK"; else echo "KO";fi
OK

[giorgiofoga]

Il fatto che copia è certo, il dubbio ed il motivo dell'intero thread, è chiedere per quale motivo impiega tutto questo tempo, a prescindere dai messaggi che, in ogni caso sono corretti.

Infatti, a condizione che la pen drive sia inserita nel sistema e correttamente riconosciuta, come accade di solito, una volta che la sequenza di copia è completa, il messaggio compare senza errori.

Io non conosco precisamente quale sia l'exit status di cp, se con lo zero identifichi successo o fallimento ma, considerato il fatto che al momento il messaggio mi compare proprio in seguito alla copia correttamente eseguita, sono ragionevolmente certo che la sintassi del cp sia corretta.

I prossimi test che farò, saranno di eliminare le cartelle git dalla directory, e rimuovere i permessi di immutabilità dal file, e vedere se la soluzione migliora cercando così di circoscrivere il problema, ma ultimamente a lavoro ho scadenze imminenti.

Vi farò sapere.

Saluti

ripeto ... con i permessi corretti 20 file centesini di secondo .... 3 anni fa a un clie facevo salvare in automatico su una pen drive i file dei database degli eventi dei 3 turni o delle singole accensioni .... in media 5 file da 10k al dì ..... personalmente ho fatto diversi test su gruppi di 1000 file ... lo scan delle porte lo faceva c++ la copia un qprocess con comando cp .... in tutto 3/4 sec .... i permessi erano quelli che riportavo sopra ....

saluti