Bug 164632 - Copying to usb mass storage too slow
Copying to usb mass storage too slow
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-29 10:49 EDT by Sinan H
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.6.12-1.1376_FC3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-04 08:49:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/usr/share/hal/fdi/95userpolicy/storage-policy.fdi (590 bytes, application/octet-stream)
2005-09-08 08:38 EDT, Sinan H
no flags Details

  None (edit)
Description Sinan H 2005-07-29 10:49:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Fedora/1.7.10-1.3.1

Description of problem:
Copying to my usb key (sony, usb2, 512M) takes ages: 2 min for 10M, average speed 92 K/s. kernel-2.6.12-1.1372_FC3

Switching back to kernel-2.6.11-1.35_FC3, works properly: 4-8M/s.

dmesg and hdparm is identical in both kernels:

dmesg:
usb 1-5: new high speed USB device using ehci_hcd and address 5
scsi1 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
  Vendor: SONY      Model: Storage Media     Rev: 1.00
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 1015808 512-byte hdwr sectors (520 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 1015808 512-byte hdwr sectors (520 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
 sda: sda1
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
usb-storage: device scan complete

hdparm -T /dev/sda1
/dev/sda1:
 Timing cached reads:   2084 MB in  2.00 seconds = 1040.60 MB/sec

hdparm -t /dev/sda1
/dev/sda1:
 Timing buffered disk reads:   36 MB in  3.14 seconds =  11.48 MB/sec

box is a Dell precision 650, XEON 2.6G

Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1372_FC3

How reproducible:
Always

Steps to Reproduce:
1.cp something /media/usbdisk
2.avg speed 92 Ko/S 

  

Actual Results:  transfer much too slow

Expected Results:  transfer speed around 5M/s

Additional info:
Comment 1 Pete Zaitcev 2005-08-11 04:05:10 EDT
This is usually a symptom of the filesystem mounted with sync option somehow.
It is not the default but from time to time it happens. May I see /proc/mounts?
Comment 2 Sinan H 2005-09-07 09:54:18 EDT
fixed in kernel 2.6.12-1.1376_FC3
Comment 3 Sinan H 2005-09-08 08:38:26 EDT
Created attachment 118592 [details]
/usr/share/hal/fdi/95userpolicy/storage-policy.fdi

userpolicy to use for proper writing speed to USB removable media.
to drop in /usr/share/hal/fdi/95userpolicy/
Comment 4 Sinan H 2005-09-08 08:47:44 EDT
oh : it is not fixed in the new kernel, I probably booted in the old one
thinking it was the new one. 

Pete: you are right, the problem is the 'sync' option. However, this seems to be
the default:
Form /usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi :

<!-- Use noatime and sync options 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">
      <merge key="volume.policy.mount_option.sync" type="bool">true</merge>
      <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>
    </match>
    <match key="@block.storage_device:storage.removable" bool="true">
      <merge key="volume.policy.mount_option.sync" type="bool">true</merge>
      <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>
    </match>
  </match>

The workaround is to use the userpolicy I attached.
...
<merge key="volume.policy.mount_option.sync" type="bool">false</merge>
...
Comment 5 Dave Jones 2006-01-16 17:18:11 EST
This is a mass-update to all currently open Fedora Core 3 kernel bugs.

Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.

As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug.  Please upgrade to this newer release, and
test if this bug is still present there.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

Thank you.
Comment 6 Dave Jones 2006-02-03 01:39:00 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 7 John Thacker 2006-05-04 08:49:56 EDT
Closing per previous comment.

Note You need to log in before you can comment on or make changes to this bug.