Pagina 5 di 6

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 18:19
da Mario Vanoni
wakkokid ha scritto: Se si usasse (cp + sync + rm) credo che si elimini questo rischio, in quanto la copia originale non viene eliminata prima di essere sicuri di aver svuotato la cache.
Davo per scontato che si usassero le vecchie regole UNIX,
sh script con sempre un "sync ; sync ; sync" finale,
nei programmi C usare fsync(2), ma non sicuro in Linux, meglio usare fdatasync(2).

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 19:11
da krisis
Ma veramente vi state attaccando a quei pochi millisecondi in cui il dato resta in cache?
Disabilito il follow up su questo thread.

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 19:23
da wakkokid
krisis ha scritto:Ma veramente vi state attaccando a quei pochi millisecondi in cui il dato resta in cache?
Disabilito il follow up su questo thread.
la discussione è nata con "cp+rm è più veloce di mv?" ... diciamo che si presta bene a discussioni sul sesso degli angeli :D .

Comunque penso che i dati possano rimanere in cache per più di qualche millisecondo.
Io ne so poco di questo argomento ma l'esempio di Vanoni è interessante, credo che in situazioni particolare si possa raggiungere anche qualche secondo di intervallo tra scrittura reale e "percepita" dal SO.
Credo che basti fare una prova: attacca un hd esterno montalo. Ora smontalo. lo fa istantanemente.
Ora riattacca lo stesso hd e montalo, fai un cp di una directory con molti dile. APPENA COMPLETATO il CP, esegui l'umount. A volte possono essere necessari anche un paio secondi per effettuare l'umount. Credo che quei secondi siano il tempo che impiega l'hd a finire di svuotare la cache sull'hd.

È un'ipotesi sensata?

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 19:38
da erio
è cosi, su chiavi usb sposti dei dati fai poweroff o reboot finche non si libera tutto il processo,non da il comando.

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 20:12
da Ansa89
erio ha scritto:finche non si libera tutto il processo,non da il comando.
Non è esatto: il comando lo dà, nel senso che inizia il procendimento di spegnimento, il quale prevede il sync di tutti i file system montati (la vera pena è quando si ha un export nfs montato e ci mette 5 minuti per colpa della rete 10 Mbps).

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 20:16
da targzeta
Secondo me ci stiamo confondendo le idee. Il problema sollevato da puzuma è fondato e lo potete testare anche voi. Vi posto il resoconto:

Codice: Seleziona tutto

$>mount /mnt/pendrive

$> ls
totale 5,3M
5,3M MPlayer-SVN_r32943.tar.bz2 

$> mv MPlayer-SVN_r32943.tar.bz2 /mnt/pendrive/

$> ls
totale 0

$> ls /mnt/pendrive
totale 5,3M
5,3M MPlayer-SVN_r32943.tar.bz2*
Il file è stato spostato correttamente giusto? Vediamo, stacco la pennina senza fare umount, come avverrebbe se mancasse la corrente o per distrazione. Faccio un umount per non creare problemi (ma la pennina non c'è!).

Codice: Seleziona tutto

$>umount /mnt/pendrive/
Riattacco la pennina:

Codice: Seleziona tutto

$> mount /mnt/pendrive/

$> ls /mnt/pendrive/
totale 0
Conclusione, il flie MPlayer-SVN_r32943.tar.bz2 è, usando le parole di puzuma, nell'iperspazio.

Però il problema non è dovuto alla cache di nessun supporto, HD o pennina (ma la pennina ha una cache?). Il problema avviene per via dell'opzione 'async' passata a 'mount',
man mount ha scritto:async
All I/O to the filesystem should be done asynchronously. (See also the sync option.)
questa opzione è di default abilitata anche quando nell'fstab (per chi la usa ancora) c'è inserito 'defaults':
man mount ha scritto:defaults
Use default options: rw, suid, dev, exec, auto, nouser, and async.
quindi è molto probabile che tutti i nostri filesystem siano montati in questo modo, ergo, se la corrente va giù effettivamente si potrebbe perdere qualche file spostato, anche se mv finisce correttamente la sua esecuzione.

Per rispondere a "wakkokid", non c'entra niente la cache del supporto. E' solo che il kernel si mette i file in memoria (se ha spazio) e non li sposta direttamente (in questo caso sulla pennina), lo farà in un secondo momento, o quando lo ritiene più opportuno o quando glielo chiediamo noi, ad esempio con 'umount'.

Emanuele

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 20:49
da Mario Vanoni
spina ha scritto: Per rispondere a "wakkokid", non c'entra niente la cache del supporto. E' solo che il kernel si mette i file in memoria (se ha spazio) e non li sposta direttamente (in questo caso sulla pennina), lo farà in un secondo momento, o quando lo ritiene più opportuno o quando glielo chiediamo noi, ad esempio con 'umount'.
Per le pennette avrai forse ragione,
ma per spostare files da un HD all'altro probabilmente erri.
Il kernel mette sulla RAM quello che puo`,
lo passa al disco, la sua cache mangia quanto e` grande,
quello assorbito non esiste piu` sulla RAM!
Con errore questa quantita` e` andata persa.
La logica HD non e` governata dal SO, e` indipendente!

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: sab 26 feb 2011, 20:52
da Trotto@81
E quali sono i casi in cui lo spostamento tra HD può andare perso?

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: dom 27 feb 2011, 14:13
da wakkokid
spina ha scritto: Per rispondere a "wakkokid", non c'entra niente la cache del supporto. E' solo che il kernel si mette i file in memoria (se ha spazio) e non li sposta direttamente (in questo caso sulla pennina), lo farà in un secondo momento, o quando lo ritiene più opportuno o quando glielo chiediamo noi, ad esempio con 'umount'.
Quindi il problema è lo stesso solo che i dati vengono "parcheggiati" in RAM anziché nella CACHE dell'HD?
Effettivamente potevo pensarci, "free" mostra anche due voci "buffers" e "cache", sarà sicuramente quello.
In tal caso il problema è anche accentuato, visto che la RAM è molto più grande della cache Hd
Potrebbe lo stesso essere un buon motivo per fare cp+sync+rm anziché mv per dati particolarmente sensibili:
(la vera pena è quando si ha un export nfs montato e ci mette 5 minuti per colpa della rete 10 Mbps)
5 minuti di "dubbio" per dati vitali, quando se avessi usato cp+sync+rm non avrei alcun dubbio!

Ovviamente, il succo del discorso è il sync tra cp e rm, come detto da meskaladmug cp+rm e mv sono la stessa cosa.

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: dom 27 feb 2011, 14:17
da wakkokid
Trotto@81 ha scritto:E quali sono i casi in cui lo spostamento tra HD può andare perso?
Se ho capito bene, qualunque caso che comprometta lo svuotamento della ram (o cache HD) sul dispositivo, evento che deve accedere nello stretto lasso di tempo tra fine del comando cp e l'effettiva fine dello svuotamento del buffer.

-Freeze / crash SO
-blackout
-scollegamento dispositivo senza umount (pendrive o hd esterni)
-problemi/cadute di connessione nella rete (nfs e filesystem di rete)
- ?

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: dom 27 feb 2011, 15:19
da Mario Vanoni
wakkokid ha scritto:Se ho capito bene, qualunque caso che comprometta lo svuotamento della ram (o cache HD) sul dispositivo, evento che deve accedere nello stretto lasso di tempo tra fine del comando cp e l'effettiva fine dello svuotamento del buffer.
Non dimenticare che mv (cp + unlink) attraversa nell'ordine
- il processore
- la sua L2 cache, L3 cache se ne ha
- la RAM del sistema
- la cache HD
- la logica HD

Il minimo errore in uno stadio ...

Anni fa il sole ha fatto una erruzione molto violenta,
luci0 probabilemte puo` citare o ricorda i fatti,
satelliti in TILT come pure computer sul pianeta.

http://www.bbc.co.uk/news/science-environment-12493980
Solar flares are caused by the sudden release of magnetic energy stored in the Sun's atmosphere.

Their effects can interfere with modern technology on Earth, such as electrical power grids, communications systems and satellites - including satellite navigation (or sat-nav) signals.

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: dom 27 feb 2011, 16:03
da krisis
Le cavallette? Perchè nessuno nomina le cavallette!!
Prima ho sentito Giacobbo di Voyager e secondo lui mv fallisce per colpa di un complotto fatto dai templari riuniti nella piramide di giza mentre invocano gli alieni.

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: dom 27 feb 2011, 16:25
da targzeta
krisis ha scritto:Le cavallette? Perchè nessuno nomina le cavallette!!
Prima ho sentito Giacobbo di Voyager e secondo lui mv fallisce per colpa di un complotto fatto dai templari riuniti nella piramide di giza mentre invocano gli alieni.
Sono d'accordo con te krisis, però devi ammettere anche tu che il topic, nonostante tutto, è stato istruttivo. Se è vero che il comando 'mv' segue l'algoritmo spiegato da masalapianta, è anche vero che il problema sollevato da puzuma è fondato, come ho cercato di far vedere con un esempio.

Emanuele

Offtopic: Ma Giacobbo ce l'ha co sti templari eh?

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: lun 28 feb 2011, 8:44
da masalapianta
Trotto@81 ha scritto:Mario è tutto fuorché uno sprovveduto
dai, basta scherzare :toothy7: :toothy7: :toothy7:

Re: mv oppure cp tra 2 filesystem diversi??

Inviato: lun 28 feb 2011, 8:47
da masalapianta
puzuma ha scritto:h
mv è vero che fa l'unlink solo a fine copia però non aspetta il flush del filesystem. Cerco si spiegare meglio il mio pensiero: sappiamo tutti che il OS non copia il file subito ma lo mette in una sorta di coda e poi lo copia quando ha tempo, è una cosa che succede continuamente con le chiavette USB, infatti quando le si va a smontare capita che la copia venga conclusa solo in quel momento. Quindi c'è almeno un caso in cui mv mi fa perdere un file: quando lo copio su un dispositivo montato senza copia sincronizzata, se tolgo il dispositivo (o va via la corrente) ecco che il mio file è rimasto nell'iperspazio senza che nessuno mi abbia dato errori.
per questo son stati creati i filesystem journaled (certo che se poi si montano con opzioni tali che, per favorire le performance, si rischia comunque di perder dati, quello non è un problema di mv o del filesystem)