Newsgroup: it.comp.os.linux.iniziare
Titolo: Copia file: rallentamenti

Buongiorno. Ho da poco preso un pc nuovo e va tutto abbastanza bene.  
Ho notato per� che quando copio una grande quantit� di dati su disco 
il pc rallenta motissimo e per alcuni secondi non ho il controllo del 
desktop. Questi blocchi sono ripetuti varie volte per tutta la durata 
della copia.
La velocit� di copia va bene, quindi non � lenta la copia ma proprio 
il pc diventa quasi ingestibile finch� la copia non � terminata.
La scheda madre � una Gigabyte GA-MA790X-UD3P.
Il disco � un seagate da 1TB.
Ho installato Debian testing AMD-64 mentre prima avevo sempre Debian 
ma a 32 bit.
Con il vecchio pc, molto meno potente, sotto questo punto di vista 
andava tutto molto meglio.
Il disco � anche molto utilizzato, nel senso che ci sono brevi accessi 
al disco ripetuti ogni 1/2 secondi anche quando il pc non � usato e 
non ci sono programmi che accedono. Sembra ci sia qualche demone che 
continua a monitorare qualcosa. Ho provato a togliere killare qualche 
processo che secondo me poteva essere l'autore i questi accessi ma non 
� cambiato nulla.
# hdparm /dev/sda
/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 121601/255/63, sectors = 1953523055, start = 0
Se servono altre info chiedete pure che le invio.
-- 
|- Massimo ;-) ---> 
http://maq.altervista.org
 <-----|(o-  POWERED |
|- BABYLON 5 -----> 
http://babylon5.altervista.org
 <|(/)_ BY LINUX|
|- STARGATE ------> 
http://sg1screw.altervista.org
 <|And the sky  |
|WHAT DO YOU WANT?> 
http://morden.deviantart.com
 <--|full of stars|

 ma a 32 bit.
Diventicavo... su entrambi i pc (quello vecchio e quello nuovo) ho 
usato il filesystem ext3.


 continua a monitorare qualcosa.
usi KDE4? e da quanto tempo ï¿œ su?
potrebbe essere strigi che sta ancora indicizzando;
quanto ai rallentamenti mentre si manipolano grandi quantitï¿œ di dati mi 
sembrano normali, se non erro ï¿œ un difetto introdotto coi kernel 2.6;
r
-- 
per snellire i processi non servirebbe annullare la prescrizione una 
volta iniziati? gli imputati non avrebbero motivi di tirarla per le 
lunghe (gli avvocati sï¿œ ;-P
Un Minuto Per Favore:
Home Page, The Pentangle, I Salon di Baudelaire: 
http://www.umpf.net

 sembrano normali, se non erro � un difetto introdotto coi kernel 2.6;
Una differenza che mi ero dimenticato � che nel vecchio pc avevo il 
kernel 2.6.26 mentre nel nuovo il 2.6.30. Che sia questo il problema?


 della copia.
Prova a controllare quale I/O scheduler stai usando, e prova ad usarne 
un'altro e vedi se le cose migliorano.
http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/

 kernel 2.6.26 mentre nel nuovo il 2.6.30. Che sia questo il problema?
non credo;
ma prima non notavi rallentamenti?


 ma prima non notavi rallentamenti?
Erano pc molto differenti a livello hardware, ma l'altro, pur essendo 
meno performante, non mi dava questi blocchi; non cos� evidenti almeno.


 
http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/
Da quello che vedo sto usando il cfq che se ho ben capito � il pi� 
diffuso ed � lo stesso che che era impostato anche sul vecchio pc.
#  cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
Ho provato ad usarne un altro ma non ho notato grandi cambiamenti.


 
Ha pi� influenza come � compilato il kernel riguardo al preemtive, se � 
impostato a no le varie operazioni vengono eseguita in sequenza (per uso 
server).
Poi potrebbe essere il desktop manager a '''sedersi''', la cosa di solito si 
nota facendo una copia pesante usando da console cp/cp -a e vedendo se il 
sistema tende ancora a rispondere a scatti.

 sistema tende ancora a rispondere a scatti.
Non uso desktop manager ma solo icewm.
La copia l'ho fatta da console ma con mc vale lo stesso?
Il sistema rimane bloccato per qualche secondo (5/10) poi il sistema 
risponde e dopo un po' torna a bloccarsi nuovamente. E cos� via per 
tutta la copia.


 tutta la copia.
IHMO il problema e' il chipset della mainboard ,non e' robaccia VIA vero ?
(magari e' una asrock)
lspci che dice ?
un  
 hdparm -Tt /dev/sda /dev/sdb
/dev/sda:
 Timing cached reads:   13480 MB in  1.99 seconds = 6771.46 MB/sec
 Timing buffered disk reads:  176 MB in  3.01 seconds =  58.46 MB/sec
/dev/sdb:
 Timing cached reads:   13506 MB in  1.99 seconds = 6784.72 MB/sec
 Timing buffered disk reads:  312 MB in  3.02 seconds = 103.43 MB/sec
Che ti dice ?

 Che ti dice ?
Adesso ho dei programmi che non posso bloccare, ma non usano il disco 
e non credo influenzino i risultati.
# hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   6112 MB in  2.00 seconds = 3057.17 MB/sec
 Timing buffered disk reads:  324 MB in  3.01 seconds = 107.70 MB/sec


  Timing buffered disk reads:  324 MB in  3.01 seconds = 107.70 MB/sec
Direi che sei scarsino,hai abilitato AHCI nel bios ? (non so' se influenza 
il tranfer rate) .
Devo pero' specificare che uso l'ultimo kernel (2.6.32.3) compilato a 
manina,non so' se puo' fare la differenza,in passato ho avuto problemi con i 
kernel debian,ho sempre preferito compilarmi gli ultimi vanilla ...
Ovviamente parliamo di un disco SATA, o no?
Immagino che il disco sia un Maxtor,non e' un 500 Gb vero ?
se lo e',cerca sul sito Maxtor se il tuo fa' parte della serie "bacata" ...

 se lo e',cerca sul sito Maxtor se il tuo fa' parte della serie "bacata" ...
E' un seagate da 1TB. Avevo chiesto un WD con cui mi sono trovato 
molto bene in passato. Andr� a protestare ma non so se me lo far� 
cambiare.
