Re: Fwd: nForce3 /usbstorage : deadly slow[FIXED, but sync is problem]

[Marcus Müller]

Thanks!Calling "sync" automated every 2 seconds (using watch) only slightly decreased performance, while speeding up the umount process extremely, and giving the feeling that the worst case scenario of an usb storage device being unplugged in the middle of a file transition loses a lot of its effect. (Note: I use my USB devices most of the time with only one to maybe 5 files simultaniously accessed, so there is not that much lost in that case, running fsck usually does the job quite well, but without any syncing the unwritten buffers would propably have been too large)
GreetingsMarcus MüllerOn 5/18/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> The problem is, that without sync, unplugging an un- umounted device is> datacide. umounting the device after transferring 700 MB takes about 24sec,> what seems to be long.You can manually run "sync" to flush stuff out to disk.
The long delay you're seeing on unmount is because "copying" the 700Mbprobably kept most of it in cache, and it hadn't finished writing it back bythe time you tried to unmount the disk.> Any idea why sync is _that_ slow with vfat
> (fat32)? Does it always have to rewrite the whole both FATs including> analyzing the actual contents of the disk whenever a file is written?The sync option ensures the data is always consistent on the drive, so I'm not
surprised you're seeing a large slowdown. Each write probably requiresseveral round-trips to update the FAT.Paul

Re: Fwd: nForce3 /usbstorage : deadly slow[FIXED, but sync is problem]

[Paul Brook]

> The problem is, that without sync, unplugging an un- umounted device is
> datacide. umounting the device after transferring 700 MB takes about 24sec,
> what seems to be long. 

You can manually run "sync" to flush stuff out to disk.
The long delay you're seeing on unmount is because "copying" the 700Mb 
probably kept most of it in cache, and it hadn't finished writing it back by 
the time you tried to unmount the disk.

> Any idea why sync is _that_ slow with vfat 
> (fat32)? Does it always have to rewrite the whole both FATs including
> analyzing the actual contents of the disk whenever a file is written?

The sync option ensures the data is always consistent on the drive, so I'm not 
surprised you're seeing a large slowdown. Each write probably requires 
several round-trips to update the FAT.

Paul


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Fwd: nForce3 /usbstorage : deadly slow[FIXED, but sync is problem]

[Marcus Müller]

I could send dmesg-output, but I just -err- fixed the problem:I found out that the loss of speed is due to the "sync" option for mount.I didn't think of mount options at first, but after I tried to format the stick with more "obscure" file system, the speed went up.
So I examined the mount options, and after a few trials I found out that the sync option slowed the whole thing down by about factor 10 (or even more), and disabled it (/etc/usbmount/...).The problem is, that without sync, unplugging an un- umounted device is datacide. umounting the device after transferring 700 MB takes about 24sec, what seems to be long. Any idea why sync is _that_ slow with vfat (fat32)? Does it always have to rewrite the whole both FATs including analyzing the actual contents of the disk whenever a file is written?
Well, I can live with having to umount usb-sticks, but I can't let my young relatives use my usbsticks :( Thanks, Marcus MüllerOn 5/18/06, Leonardo Lanzi
 <[EMAIL PROTECTED]> wrote:

Dear Marcus,could you send also the lines in /var/log/messages related to thehardware detection of the usb storage and to the device associated to it?Something similar to:...May 11 09:25:49 xxx kernel: usb 
4-1.1: new high speed USB device usingehci_hcd and address 5May 11 09:25:49 xxx kernel: Initializing USB Mass Storage driver...May 11 09:25:49 xxx kernel: scsi0 : SCSI emulation for USB Mass Storagedevices
May 11 09:25:49 xxx kernel: usbcore: registered new driver usb-storageMay 11 09:25:49 xxx kernel: USB Mass Storage support registered.May 11 09:25:54 xxx kernel: sda: assuming drive cache: write throughMay 11 09:25:54 xxx kernel: sda: assuming drive cache: write through
May 11 09:25:54 xxx kernel: sda: sda1...CiaoLeonardoMarcus Müller wrote:> I have a problem with my debian system on my Asus K8N board, which is> nForce3 250 based:> whenever i plug in a 
USB2.0-enabled storage device (in my case recently> a 1GB Creative Muvo TX SE), the kernel recognizes it as USB-2.0 device,> the ehci_hcd module gets loaded, usbview and all other sources tell me> that it is a 480MB/s device :
>  Speed: 480Mb/s (high)>  USB Version:  2.00> But: I never even reach a transfer rate of 800kB/s (which would only be> 1/600 of the maximum thinkable speed). Instead, it writes files with
> about 200 kB/s, until after a few seconds, the transfer rate collapses> to 80kB/s, which is not only bad but ugly.> On the same machine, booted with an i386 2.6-kernel from CDROM (Knoppix> 4.0.1

), the device is only recognized as USB1.1 full speed device, but> still transfers a lot faster than under debian/amd64.>> I examined my loaded modules and wasn't able to make out any> chipset-specific modules, only some i2c-nforce modules (lsmod output
> attached), are there any modules I have to load /unload to make it work> or do You have any other suggestion?>> Thanks,>> Marcus Müller>>> 
>> Module  Size  Used by> nls_iso8859_1   5568  1> nls_cp437   7296  1> vfat   13440  1> fat51824  1 vfat

> sd_mod 17880  2> vmnet  30552  7> vmmon 181944  0> binfmt_misc12176  1> thermal15308  0> fan 5384  0
> button  7840  0> processor  24600  1 thermal> ac  5704  0> battery10760  0> lp 12864  0> ipv6  252256  17
> reiserfs  226352  3> dm_mod 53800  0> nvram   8392  0> i2c_dev10720  0> msr 3976  0> nvidia   4856084  18
> aes27112  0> cryptoloop  4288  0> loop   15760  1 cryptoloop> it87   24356  0> hwmon_vid   3008  1 it87
> i2c_isa 5952  1 it87
> ide_generic 1600  0 [permanent]> usb_storage80128  1> usbhid 34720  0> snd_intel8x0   34536  1> snd_ac97_codec102012  1 snd_intel8x0
> snd_ac97_bus2880  1 snd_ac97_codec> analog 10784  0> snd_pcm_oss51296  0> snd_mixer_oss  17472  1 snd_pcm_oss> psmouse39308  0
> i2c_nforce2 7808  0> serio_raw   7748  0> ide_cd 40224  1> cdrom  36280  1 ide_cd> gameport   15824  1 analog> snd_mpu401  9440  0
> snd_mpu401_uart 7872  1 snd_mpu401> snd_pcm89932  3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss> i2c_core   23064  4 i2c_dev,it87,i2c_isa,i2c_nforce2> shpchp 45120  0
> pci_hotplug11716  1 shpchp> forcedeth  23876  0> ehci_hcd   30344  0> ohci_hcd   19716  0> parport_pc 36592  1> parport