# [SOLVED] usb transfer files very slow

## paul555

Hi all yesterday i tried to transfer a 170 MB file from my sata hd to my usb stick which it is connected via usb2 and it took about 1 hour   :Sad:   .After that i tried hdparm and it gave me that output :

```
medic paul # hdparm -t -T /dev/sdb

/dev/sdb:

 Timing cached reads:   1132 MB in  2.00 seconds = 564.67 MB/sec

 Timing buffered disk reads:   16 MB in  3.17 seconds =   5.04 MB/sec 
```

Here the output from

lsusb command :

```
medic paul # lsusb

Bus 003 Device 005: ID 4586:1026

Bus 003 Device 004: ID 03f0:1604 Hewlett-Packard DeskJet 940c

Bus 003 Device 003: ID 03f0:0405 Hewlett-Packard ScanJet 3400cse

Bus 003 Device 002: ID 050f:0003 KC Technology, Inc. KC82C160S Hub

Bus 003 Device 001: ID 0000:0000

Bus 002 Device 001: ID 0000:0000

Bus 001 Device 001: ID 0000:0000

```

and the output of dmesg :

```
medic paul # dmesg |grep usb

usb-storage: Bulk status result = 0

usb-storage: Bulk Status S 0x53425355 T 0x184 R 0 Stat 0x0

usb-storage: scsi cmd done, result=0x0

usb-storage: *** thread sleeping.

usb-storage: queuecommand called

usb-storage: *** thread awakened.

usb-storage: Command TEST_UNIT_READY (6 bytes)

usb-storage:  00 00 00 00 00 00

usb-storage: Bulk Command S 0x43425355 T 0x185 L 0 F 0 Trg 0 LUN 0 CL 6

usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes

usb-storage: Status code 0; transferred 31/31

usb-storage: -- transfer complete

usb-storage: Bulk command transfer result=0

usb-storage: Attempting to get CSW...

usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes

usb-storage: Status code 0; transferred 13/13

usb-storage: -- transfer complete

usb-storage: Bulk status result = 0

usb-storage: Bulk Status S 0x53425355 T 0x185 R 0 Stat 0x0

usb-storage: scsi cmd done, result=0x0

usb-storage: *** thread sleeping.

usb-storage: queuecommand called

usb-storage: *** thread awakened.

usb-storage: Command TEST_UNIT_READY (6 bytes)

usb-storage:  00 00 00 00 00 00

usb-storage: Bulk Command S 0x43425355 T 0x186 L 0 F 0 Trg 0 LUN 0 CL 6

usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes

usb-storage: Status code 0; transferred 31/31

usb-storage: -- transfer complete

usb-storage: Bulk command transfer result=0

usb-storage: Attempting to get CSW...

usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes

usb-storage: Status code 0; transferred 13/13

usb-storage: -- transfer complete

usb-storage: Bulk status result = 0

usb-storage: Bulk Status S 0x53425355 T 0x186 R 0 Stat 0x0

usb-storage: scsi cmd done, result=0x0

usb-storage: *** thread sleeping.

```

Any suggestions?Please help   :Sad: 

----------

## fourhead

Are your sure that USB2 is enabled in the kernel? If yes, how did you mount the USB stick? Do NOT mount it with the 'sync' option!

Tom

----------

## paul555

I have compiled-in support for usb 2  *Quote:*   

> <*>   EHCI HCD (USB 2.0) support

 .My usb stick mounted automatically from gnome-volume-manager.I use  sys-fs/udev-058 sys-apps/hal-0.4.7-r2 sys-apps/dbus-0.23-r3 gnome-base/gnome-volume-manager-1.2.2 .Any ideas?

----------

## fourhead

Look into

/usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi

there you'll find a section that enables the "sync" option for all removable media <2GB (or 5GB, I don't remember). Just set the bool value from 'true' to 'false' and your USB stick will no longer be mounted with the sync option. Be carefull when removing the stick! First unmount it and let it write all data. I don't know how Gnome does that, but in KDE there's a green arrow showing that the stick is mounted, and this arrow does not disappear before all data is written to the stick.

Tom

----------

## paul555

It worked ok thanks   :Smile:   .I just edit the line of the /usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi  *Quote:*   

> <merge key="volume.policy.mount_option.sync" type="bool">true</merge>

  to  *Quote:*   

> <merge key="volume.policy.mount_option.sync" type="bool">false</merge>

 .But why is that it is a bug with hal?Anyway thanks

----------

## fourhead

No, it's not a bug with hal, hal makes it right, using 'sync' for removable media makes sense, I've read somewhere it's a bug in liux 2.6.13, or to be precise, in it's vfat module. Don't know if this is intended behaviour and/or if it wil be fixed ...

Tom

----------

## paul555

Well i use gentoo-sources 2.6.12-r6

----------

## Elim

well its also in 2.6.14-rc1 so they havn't fixed it yet, and this solution worked perfectly thanks.

----------

## fourhead

Um, well it may have been 2.6.12, I thought it was 2.6.13, well at least in the thread where I found this solution somebody said this bug suddenly appeared with one of the recent kernels and hal didn't change anything, so it definitely a kernel thing and not the fault of hal. Glad I was able to help  :Smile: 

Tom

----------

## thesnowman

Sorry for the bump.  Just wanted to point out the Gentoo and kernel bugs relating to this issue.

----------

## lbrtuk

 *thesnowman wrote:*   

> Sorry for the bump.  Just wanted to point out the Gentoo and kernel bugs relating to this issue.

 

Those bugs are very annoying, because the gentoo one is closed saying 'Upstream will fix / has fixed this.', but the upstream one is closed basically saying 'Won't fix.'.

So it would seem nothing's really happening.

IMHO just using the nosync option is not a good permanent solution as it causes confusion to non clued-up users.

----------

## yanos

That's strange, I don't have these files. All I have are 

```

ll /usr/share/hal/fdi/policy/10osvendor/

total 24K

-rw-r--r--  1 root root  987 Jan 21 13:02 10-laptop-panel-mgmt-policy.fdi

-rw-r--r--  1 root root 2.0K Jan 21 13:02 10-power-mgmt-policy.fdi

-rw-r--r--  1 root root 8.6K Jan 21 13:02 10-storage-policy.fdi

-rw-r--r--  1 root root  699 Jan 21 13:02 15-storage-luks.fdi

ll /usr/share/hal/fdi/policy/20thirdparty/

total 0

```

So I created /usr/share/hal/fdi/policy/90defaultpolicy/storage-policy.fdi and /usr/share/hal/fdi/policy/95userpolicy/nosync.fdi (based on another post) with this inside:

```

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->

<!-- This file overrides default HAL behavior by mounting removable volumes

without sync. This dramatically speeds up write times, but requires that

volumes be unmounted before disconnecting them. The file also

allows users to unmount removable volumes. -->

<deviceinfo version="0.2">

<device>

   <!-- Use noatime, but make "sync" false and allow users to unmount,

   for all hotpluggable or removable volumes smaller than 2GB -->

   <match key="volume.size" compare_lt="2147483648">

   <match key="@block.storage_device:storage.hotpluggable" bool="true">

   <!-- set sync = false -->

   <merge key="volume.policy.mount_option.sync" type="bool">false</merge>

   <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>

   <!-- added this option so that regular users can unmount the drive -->

   <merge key="volume.policy.mount_option.users" type="bool">true</merge>

   </match>

   <match key="@block.storage_device:storage.removable" bool="true">

   <!-- set sync = false -->

   <merge key="volume.policy.mount_option.sync" type="bool">false</merge>

   <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>

   <!-- added this option so that regular users can unmount the drive -->

   <merge key="volume.policy.mount_option.users" type="bool">true</merge>

   </match>

   </match>

</device>

</deviceinfo>

```

No luck.

----------

## yanos

Forgot to add that I also tried to modify 10-storage-policy.fdi with the same content (removing redundant parts, of course).

----------

## Drone1

It has been pointed out in several threads, including this one, that using the sync option with USB drives is slow and can possibly damage the drive. 

I am wondering why exactly, is this the case.

My own tests gave me the following results:

- USB 2.0 support in kernel (verified w/ /proc/bus/usb/devices   && udevmonitor during drive insertion)

- PNY Attache 1GB usb 2.0 thumbdrive

- 90MB file transfer to drive

sync : sustained 760+ KB/s  throughout entire transfer

async : sustained 5.1 MB/s ~75%, then dropped to 700 KB/s, then to 100 KB/s , then back up to 600 KB/s and finished around that.

Frankly, in terms of consistency to me, sync appears a more stable choice during the actual transfer. The async setting allowed a burst transfer, but then a quick transfer degradation, still slower transfer and then a slow ramp up to a 10% initial rate of finish; in terms of speed.

If sync is the more dangerous choice, I will gladly stick with it, when async appears that it won't even finish.

----------

