[Debian]Problema con usb hi-speed

[Serpico78]

Il problema è questo:
con una pennina usb da 1GB (Verbatim), sotto Debian (con l'hardware in sign) non mi riesce a scriverci in modalità hi-speed ma a leggerci in hi-speed ci riesce benissimo ! (e ciò mi fa inc***re come una iena).
In sostanza in lettura va tranquillamente oltre i 14 MB/s, in scrittura non arriva neanche a 1MB/s (di media si attesta sugli 800 KB/s).
Per circoscrivere il problema l'ho provata anche con Windows e con un Knoppix live (4.0.2) e in entrambi i casi ha funzionato senza problemi (quindi non è un problema di hardware).
A livello di kernel (già ricompilato varie volte) ho attivato sia le voci su USB (ehci etc...) e il supporto ai dischi scsi (statico perchè ho i dischi Sata), dai log sembra tutto a posto ma poi non funziona come dovrebbe.

/var/log/messages

Nov 27 21:19:30 dome kernel: usb 1-6: new high speed USB device using ehci_hcd and address 3
Nov 27 21:19:30 dome kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Nov 27 21:19:35 dome kernel: Vendor: VBTM Model: Store 'n' Go Rev: 1.02
Nov 27 21:19:35 dome kernel: Type: Direct-Access ANSI SCSI revision: 00
Nov 27 21:19:36 dome kernel: SCSI device sdc: 2013184 512-byte hdwr sectors (1031 MB)
Nov 27 21:19:36 dome kernel: sdc: Write Protect is off
Nov 27 21:19:36 dome kernel: SCSI device sdc: 2013184 512-byte hdwr sectors (1031 MB)
Nov 27 21:19:36 dome kernel: sdc: Write Protect is off
Nov 27 21:19:36 dome kernel: sdc: sdc1
Nov 27 21:19:36 dome kernel: Attached scsi removable disk sdc at scsi2, channel 0, id 0, lun 0

/var/log/syslog

Nov 27 21:19:30 dome kernel: usb 1-6: new high speed USB device using ehci_hcd and address 3
Nov 27 21:19:30 dome kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Nov 27 21:19:30 dome kernel: usb-storage: device found at 3
Nov 27 21:19:30 dome kernel: usb-storage: waiting for device to settle before scanning
Nov 27 21:19:35 dome kernel: Vendor: VBTM Model: Store 'n' Go Rev: 1.02
Nov 27 21:19:35 dome kernel: Type: Direct-Access ANSI SCSI revision: 00
Nov 27 21:19:36 dome kernel: SCSI device sdc: 2013184 512-byte hdwr sectors (1031 MB)
Nov 27 21:19:36 dome kernel: sdc: Write Protect is off
Nov 27 21:19:36 dome kernel: sdc: Mode Sense: 23 00 00 00
Nov 27 21:19:36 dome kernel: sdc: assuming drive cache: write through
Nov 27 21:19:36 dome kernel: SCSI device sdc: 2013184 512-byte hdwr sectors (1031 MB)
Nov 27 21:19:36 dome kernel: sdc: Write Protect is off
Nov 27 21:19:36 dome kernel: sdc: Mode Sense: 23 00 00 00
Nov 27 21:19:36 dome kernel: sdc: assuming drive cache: write through
Nov 27 21:19:36 dome kernel: sdc: sdc1
Nov 27 21:19:36 dome kernel: Attached scsi removable disk sdc at scsi2, channel 0, id 0, lun 0
Nov 27 21:19:36 dome kernel: usb-storage: device scan complete

Dai log sembra tutto regolare ma continua a non funzionare....
Qualcuno ha qualche suggerimento?

Thanks.
Serpico

[Serpico78]

Dimenticavo, ho provato sia con il kernel 2.6.12 (lo stesso su cui gira la Knoppix) che con il kernel 2.6.14 e il risultato è stato sempre lo stesso.
Si accettano consigli e suggerimenti; se anche qualcun altro ha avuto problemi simili può riportarli qui (e sopratutto, se è riuscito a risolverli, come ).

[Serpico78]

Risolto (anche se mi sento un pochino deficiente).
Bastava togliere l'opzione "sync" dal /etc/fstab nella riga per il montaggio della panna usb, opzione che mi pare di ricordare fosse consigliata per evitare che il file fosse trasferito realmente solo al momento della rimozione della penna, che a quanto pare era il responsabile del rallentamento della penna.

Anche se leggendo dal man mount:

sync All I/O to the file system should be done synchronously.

non riesco a capire il perchè del rallentamento....

[tohni]

Il rallentamente è giustificato dal fatto che prima scriveva in modo sincrono, mentre adesso che è in asincrono aspetta che si riempia la cache per poi copiarla sul dispositivo.
In asincrono risci di perdere dei dati se "togli" la chiavetta senza smontare il filesystem, mentre in sincrono ciò non dovrebbe succedere.

[ilsensine]

Originariamente inviato da tohni

Il rallentamente è giustificato dal fatto che prima scriveva in modo sincrono, mentre adesso che è in asincrono aspetta che si riempia la cache per poi copiarla sul dispositivo.

E' ancora più oneroso di quello che potrebbe sembrare, in quanto ogni scrittura di un blocco implica un aggiornamento (sincrono!) della fat. Quindi, tempi biblici per la scrittura (e vita della penna ridotta).

Va bene togliere sync, basta ricordarsi di non staccare la penna senza preavviso. Alcuni sviluppatori stanno lavorando su una modalità che è una via di mezzo tra sync e async per la fat32, ovvero effettuando il sync solo alla chiusura dei file. Così facendo si evitano tutte le scritture intermedie (inutili) sulla fat.

[Serpico78]

Originariamente inviato da ilsensine

E' ancora più oneroso di quello che potrebbe sembrare, in quanto ogni scrittura di un blocco implica un aggiornamento (sincrono!) della fat. Quindi, tempi biblici per la scrittura (e vita della penna ridotta).

Ogni blocco (se non mi sbaglio) è di 512 byte, la penna è da 1031 MB, se si fermava ogni blocco per fare la scrittura sincrona per forza che per copiare un file da ~ 700 MB ci metteva più di mezz'ora!!
Io pensavo che il sincronismo lo applicasse solo alla fine della copiatura del file non per ogni blocco !

Originariamente inviato da ilsensine

Va bene togliere sync, basta ricordarsi di non staccare la penna senza preavviso. Alcuni sviluppatori stanno lavorando su una modalità che è una via di mezzo tra sync e async per la fat32, ovvero effettuando il sync solo alla chiusura dei file. Così facendo si evitano tutte le scritture intermedie (inutili) sulla fat.

Ok! non è un problema, faccio sempre la rimozione sicura prima di staccarla.

Per il sync, si comporta così solo per la fat32?
Io l'ho attivato anche su file system NFS e non mi sembra una così grande causa di rallentamenti.

[ilsensine]

Originariamente inviato da Serpico78

Per il sync, si comporta così solo per la fat32?

Il suo comportamento dipende dal tipo di fs. La fat32 prevede un mapping nella fat sull'utilizzo dei blocchi, quindi il comportamento del sync "puro" è corretto.

Un fs con ordered data journal (ext3, reiserfs, forse ntfs per windows), senza il sync, sarebbe più idoneo.