Velocità imbarazzanti di copia file nautilus/dolphin

[davethecipo]

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

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:

 

[EmanueleC]

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".

Quindi confermi che non è un problema di btrfs?

 

[tunnel]

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.

 

[davethecipo]

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:

 

[signore del tempo]

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ò.

 

[davethecipo]

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.

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ò.

Ciò che temevo. Conosci un profiler? A cercare velocemente su google ho trovato "perf"

 

[signore del tempo]

Ciò che temevo. Conosci un profiler? A cercare velocemente su google ho trovato "perf"

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.

 

[davethecipo]

Sospetto che sia CPU bound: kio_file o nautilus non sembrano multicore e spremono un core al massimo. Se scopro qualcosa, vi tengo aggiornati.

 

[signore del tempo]

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:

 

[centoventicinque]

a me nautilus va benissimo su f2sf , poco peggio su brtfs .

in compenso su fatXY fa schifo

 

[davethecipo]

a me nautilus va benissimo su f2sf , poco peggio su brtfs .

in compenso su fatXY fa schifo

In effetti volevo provare f2fs ma kubuntu non lo supporta per l'installazione. Se ho sbatti riprovo i test su arch.

 

[centoventicinque]

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