Velocità imbarazzanti di copia file nautilus/dolphin

Pubblicità
davethecipo

davethecipo

Utente Èlite
Messaggi
3,332
Reazioni
1,163
Punteggio
138
Ciao a tutti,

se avete voglia e tempo, vi chiederei di provare a copiare tanti file di piccole dimensioni con nautilus e dolphin, per capire se sono l'unico con questo problema.

Adesso spiego qualche dettaglio.

SSD samsung 840 evo 512 GB, partizioni / e /home btrfs allineate a 6144. Nella home copio dei file, variabili di dimensioni da pochi MB a qualche KB. Le cartelle con files da pochi KB contengono dei repository git, giusto per informazione.

Sono su kubuntu 14.10 64bit, kernel 3.16.0-23-generic, KDE 4.14.1. Ma dubito che queste informazioni siano importanti, ho avuto modo di verificare la stessa cosa su samsung 830 128 GB tempo addietro con arch linux.

Akonadi e ricerca desktop sono disabilitati.

Con btrfs senza opzione alcuna eseguo una sola prova con dolphin ottenendo un tempo talmente imbarazzante che non l'ho nemmeno segnato.

Allora modifico /etc/fstab aggiungendo alle opzioni di mount "compress=lzo,ssd,noatime,discard". Riavvio. Con dolphin copio 1.5 GB in 1'43'', e noto che il processo kio_file usa un core della CPU al 100%. Risultato simile con nautilus, stessi file copiati in 1'23'' (in questo caso è il processo nautilus ad usare un core).

Poi provo da terminale
Codice: 
time cp -R daqua/ aqua/

ottenendo 2.5''! Oh grazie, questo è un tempo ragionevole...

Preciso inoltre che questi due file manager vanno come una lippa con file di grosse dimensioni (macchine virtuali, iso, video).

Ciao :ciaociao:
 
Ultima modifica:
Quindi il problema è dei file manager, che non gestiscono più core?
Comunque su un ssd, è quasi d'obbligo scegliere quelle opzioni al mount:
Allora modifico /etc/fstab aggiungendo alle opzioni di mount "compress=lzo,ssd,noatime,discard".
Clicca per espandere...
Quindi confermi che non è un problema di btrfs?
 
Non sono meravigliato, se il cp va bene la rete è OK. Se copi con nautilus selezionando un numero di cartelle sottocartelle e file molto alto, prima di copiare deve caricare in memoria tutti i path e nomi, se sono tantissimi a volte neanche ce la fa.
 
DIrei che non è un problema di btrfs! Il comando cp da terminale va come una lippa. Sono i file manager che ciucciano CPU per fare chissà cosa. Inoltre ho provato btrfs per cambiare, fino ad ora ho sempre usato ext4.

Se può servire, non ho partizione di swap (8GB di RAM...).

Sono tentato di scavare un po', se necessario aprire un bug report, però mi servono più dettagli. Proverò strace, però non so se basta. :grat:
 
Ho notato ciò anche io, maggiormente a causa di stalli nel trasferimento (alla fine in particolare). Una motivazione (0.02$) potrebbe stare in un probabile sync/syncfs (2) che dunque forza la scrittura su hdd.

Potresti provare con strace ma non so se c'è un opzione per vedere in quale syscall il processo spende più tempo; di solito si usa un profiler per ciò.
 
signore del tempo ha detto:
Ho notato ciò anche io, maggiormente a causa di stalli nel trasferimento (alla fine in particolare). Una motivazione (0.02$) potrebbe stare in un probabile sync/syncfs (2) che dunque forza la scrittura su hdd.
Clicca per espandere...

Giusto, ho notato pure io il rallentamento all'ultimo file, ho dimenticato di scriverlo!

Potresti provare con strace ma non so se c'è un opzione per vedere in quale syscall il processo spende più tempo. Di solito si usa un profiler per ciò.
Clicca per espandere...

Ciò che temevo. Conosci un profiler? A cercare velocemente su google ho trovato "perf"
 
Davide Olianas ha detto:
Ciò che temevo. Conosci un profiler? A cercare velocemente su google ho trovato "perf"
Clicca per espandere...
valgrind con --tool=callgrind. Ma non so quanto effettivo possa essere senza informazioni di debugging, oltre al fatto che analizzerà tutto il program flow (dovrebbe essere possibile fare il profiling di alcune parti, ma suppongo servirebbero i sorgenti).
Poi andrebbe analizzato se si tratta di un problema CPU bound o I/O bound.
 
Sospetto che sia CPU bound: kio_file o nautilus non sembrano multicore e spremono un core al massimo. Se scopro qualcosa, vi tengo aggiornati.
 
strace -e trace=file -tt dolphin rivela tutte le attività che riguardano i file: c'è senz'altro un grande lavoro nello "stat"ting, ma non vedo stalli :grat:
 
fai una installazione a tradimento :

installa con /boot separata e / in ext4 ed installa i tool f2fs

copia a manina i file di / in una partizione f2fs

edita fstab

risolto
 
Pubblicità
Pubblicità
Indietro
Top