Bug 167174 - USB Storage *very* slow after kernel upgrade
USB Storage *very* slow after kernel upgrade
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-31 06:37 EDT by Wieland
Modified: 2013-03-05 22:44 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 01:34:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wieland 2005-08-31 06:37:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111

Description of problem:
After I upgraded my kernel version to 2.6.12-1.1372_FC3, transferring data to my USB memory stick became very slow. Upgrading to 2.6.12-1.1376_FC3 didn't fix the problem. It took me 70 minutes to copy 41MB to the device. The USB device used to work without problems in previous kernels, and works fine with WinXP too.
This issue is also discussed at http://www.linuxquestions.org/questions/history/349773 , but I couldn't find a bug, so I thought I'd report it myself.

/var/log/messages shows no problems.


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

How reproducible:
Always

Steps to Reproduce:
1.Plug in USB memory stick
2.Mount it
3.Try to transfer large amount of data to memory stick
  

Actual Results:  My files were copied *very* slowly. 40MB took 70 minutes to transfer.

Expected Results:  The files should be transferred reasonably fast.

Additional info:

USB1.1 (I think), using ohci drivers.

Please feel free to mail me if you need more info.
Comment 1 Pete Zaitcev 2005-08-31 19:12:52 EDT
Most of the time it's "sync". Please post the full contents of /proc/mounts.
Comment 2 C Sand 2005-09-01 03:24:33 EDT
I can confirm this bug, which occurs when accessing a Creative MuVO TX FM music
player (which is accessed as a USB 2.0 drive). When using kernels earlier than
2.6.12-1.1372_FC3, the access was mighty quick.  Right now it is verging on
being unuseable.

The culprit is either in the kernel, and/or on the following line in /etc/fstab,
which seems to be automatically generated by HAL/udev/hotplug:

/dev/sda1 /media/usbdisk vfat
pamconsole,exec,noauto,iocharset=utf8,noatime,sync,managed 0 0

The problem seems to be the "sync" option. I have searched for a way to modify
the line that is being written to /etc/fstab, but to no avail.
Comment 3 Wieland 2005-09-01 03:26:51 EDT
Here's /proc/mounts:

rootfs / rootfs rw 0 0
/proc /proc proc rw,nodiratime 0 0
none /dev tmpfs rw 0 0
/dev/root / ext3 rw 0 0
none /dev tmpfs rw 0 0
none /selinux selinuxfs rw 0 0
/proc /proc proc rw,nodiratime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw 0 0
/sys /sys sysfs rw 0 0
none /dev/pts devpts rw 0 0
/dev/hda2 /boot ext3 rw 0 0
none /dev/shm tmpfs rw 0 0
/dev/hda1 /mnt/windows ntfs
ro,noatime,nodiratime,uid=500,gid=501,umask=00,nls=utf8,errors=continue,mft_zone_multiplier=1
0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
/dev/sda1 /media/usbdisk vfat
rw,sync,noatime,nodiratime,nosuid,nodev,uid=500,gid=500,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8
0 0
Comment 4 Wieland 2005-09-01 03:47:11 EDT
I booted into two previous kernels to check. The 'sync' option gets added in
2.6.12-1.1372_FC3 and 2.6.12-1.1376_FC3, both of which show this problem. It's
not there in 2.6.11-1.35_FC3 however, and USB works fine in that release.
Comment 5 C Sand 2005-09-01 04:35:07 EDT
... so this appears to be hard-coded into the kernel.  The obvious question: is
there a user-space configuration file to override the default kernel behaviour?
Comment 6 Dmitry Butskoy 2005-09-01 10:51:31 EDT
  For me, with latest kernel-2.6.12-1.1376_FC3, all is OK.

  I mount USB stogage from cmdline as "mount /dev/sda1 /mnt", then "cat
/proc/mounts" do not show me any "sync" options. IO is fast.

  IMHO, the "sync" option is added by some desktop utilities (which mount USB
storage as it is inserted immediately...). Try to write an appropriate string in
/etc/fstab (i.e. "/dev/sda1 /media/usbdisk auto defaults,noauto,noatime 0 0").
Comment 7 Pete Zaitcev 2005-09-01 12:33:00 EDT
David, care to comment from HAL's point of view? In particular, can this
be overridden with a configuration, and if an update RPM for HAL is feasible.

I do not see this problem on FC4. Entries look like this:

/dev/sda1               /media/KINGSTON         vfat   
pamconsole,exec,noauto,managed 0 0

/dev/sda1 /media/KINGSTON vfat
rw,nodiratime,nosuid,nodev,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii 0 0

hal-0.5.2-2

Looks like an FC3-specific problem.
Comment 8 Wieland 2005-09-01 19:05:04 EDT
(In reply to comment #6)
>   IMHO, the "sync" option is added by some desktop utilities (which mount USB
> storage as it is inserted immediately...). 

Not on my system. I don't use any desktop utilities for (auto)mounting my USB
stick, I always mount it from a terminal. And I'm having the same problem in
runlevel 3.
Comment 9 Dmitry Butskoy 2005-09-02 05:42:29 EDT
  What is your /etc/fstab file?
  Before the USB inserting and after USB is inserted?
Comment 10 David Zeuthen 2005-09-02 11:18:04 EDT
It became clear, from LKML a few months back, that adding 'sync' is a bad idea
with newer kernels that actually implement 'sync'. So this is potentially a bug
in HAL. I thought I pushed an FC3 update that doesn't add the 'sync' option? Can
anyone confirm that the latest FC3 update of hal (please give the full N-V-R)
adds 'sync'?
Comment 11 Pete Zaitcev 2005-09-02 12:01:39 EDT
I, too, thought David addressed it. So, Wieland has to post his "rpm -q hal".
Maybe it's just old. Also, "I always mount from terminal" is not sufficient.
We need to know what mount point was used. I also mount from terminal only,
but I use "mount /media/usbdisk", which obeys flags that fstab-sync added.
Comment 12 Wieland 2005-09-02 18:37:13 EDT
Right, here goes: My HAL version is hal-0.4.7-1.FC3.

1. I mount my USB disk  with 'mount /media/usbdisk'.

2. This is what /etc/fstab looks like before mounting the USB key:

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /proc                   proc    defaults        0 0
none                    /dev/shm                tmpfs   defaults        0 0
/dev/hda5               swap                    swap    defaults        0 0
/dev/hda1               /mnt/windows            ntfs   
uid=wieland,gid=winusers,umask=000 0 0
/dev/hdc                /media/cdrecorder       auto   
pamconsole,exec,noauto,managed 0 0
/dev/hdb                /media/cdrom            auto   
pamconsole,exec,noauto,managed 0 0


This is my /etc/fstab after inserting the USB key:
LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /proc                   proc    defaults        0 0
none                    /dev/shm                tmpfs   defaults        0 0
/dev/hda5               swap                    swap    defaults        0 0
/dev/hda1               /mnt/windows            ntfs   
uid=wieland,gid=winusers,umask=000 0 0
/dev/hdc                /media/cdrecorder       auto   
pamconsole,exec,noauto,managed 0 0
/dev/hdb                /media/cdrom            auto   
pamconsole,exec,noauto,managed 0 0
/dev/sda1               /media/usbdisk          vfat   
pamconsole,exec,noauto,iocharset=utf8,noatime,sync,managed 0 0

As you can see, the USB key gets added (by HAL, presumably) to /etc/fstab with
the 'sync' option.
Comment 13 C Sand 2005-09-02 21:21:22 EDT
Relevant packages on my system, which is affected by the slow USB problem:

hal-0.4.7-1.FC3
kernel-2.6.12-1.1376_FC3
udev-039-10.FC3.7
hotplug-2004_04_01-8

Comment 14 Dmitry Butskoy 2005-09-05 06:54:44 EDT
  For comment #10 :
>I thought I pushed an FC3 update that doesn't add the 'sync' option? Can
>anyone confirm that the latest FC3 update of hal (please give the full N-V-R)
>adds 'sync'?

  Current FC3`s hal is hal-0.4.7-1.FC3
  See the line 154 at /usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi .
The "sync" option is added...
Comment 15 Rob Prior 2005-09-10 12:02:37 EDT
For what it's worth, i'm also running the 1376 kernel.  I checked my
/proc/mounts, and the sync option was there.  I unmounted the USB drive manually
(command line), then edited my /etc/fstab whch had the sync option in it.  I
removed the sync option, then remounted manually.  /proc/mounts now shows no
sync option, but the slow performance is still present.

Sandisk Cruzer USB 1.0G
kernel-2.6.12-1.1376

Everything else up-to-date using up2date.  Up to 35 minutes now to run a
synchronize on two folders, when it usually takes about 5 minutes.
Comment 16 Dmitry Butskoy 2005-09-12 06:03:03 EDT
 In my case all is OK:
kernel-2.6.12-1.1376,
Transcend JetFlash 2.0Gb,
270Mb copied by ~30sec ...
Comment 17 Fernando Perez 2005-09-13 14:20:57 EDT
I was having the same problem (with a 512 MB USB stick).  This simple change:

root@planck[90defaultpolicy]# pwd
/usr/share/hal/fdi/90defaultpolicy

root@planck[90defaultpolicy]# diff storage-policy.fdi storage-policy.fdi.ori
162c162
<             <merge key="volume.policy.mount_option.sync" type="bool">false</merge>
---
>             <merge key="volume.policy.mount_option.sync" type="bool">true</merge>

Fixed it.  No reboot necessary, just change 'true' to 'false' in the sync option
 and that seems to do it.  Until a HAL update comes around which implements
this, it seems like an easy enough fix to apply manually.

HTH.
Comment 18 Fernando Perez 2005-09-13 21:45:47 EDT
Just an extra comment: on my laptop at home I had to make the same change as
above (true->false in policy file) also on line 162:

root[90defaultpolicy]# diff storage-policy.fdi storage-policy.fdi.ori
158c158
<             <merge key="volume.policy.mount_option.sync" type="bool">false</merge>
---
>             <merge key="volume.policy.mount_option.sync" type="bool">true</merge>
162c162
<             <merge key="volume.policy.mount_option.sync" type="bool">false</merge>
---
>             <merge key="volume.policy.mount_option.sync" type="bool">true</merge>

Just in case someone needs this fix.
Comment 19 Wieland 2005-09-14 01:55:37 EDT
Fernando's fix works for me. (Thank you!).
Comment 20 Didier Heyden 2005-10-02 13:34:50 EDT
With my Kingston DataTraveler 2.0 (256 Mb), the 'nosync/sync' speed ratio is
about 5:1 for a VFAT filesystem and 2.7:1 for an EXT2 filesystem.

# ~50 Mb file
$ ls -l backup.tar.gz
-rw-r--r--  1 root root 51293567 Jul 30 12:34 backup.tar.gz

# VFAT with 'sync'
$ time cp backup.tar.gz /media/KINGSTON/; time umount /media/KINGSTON

real    2m48.492s
user    0m0.010s
sys     0m0.618s

real    0m0.036s
user    0m0.001s
sys     0m0.030s

# VFAT without 'sync'
$ time cp backup.tar.gz /media/KINGSTON/; time umount /media/KINGSTON

real    0m2.103s
user    0m0.005s
sys     0m0.206s

real    0m30.425s
user    0m0.001s
sys     0m0.132s

# EXT2 with 'sync'
$ time cp backup.tar.gz /media/KINGSTON/; time umount /media/KINGSTON

real    3m49.324s
user    0m0.015s
sys     0m0.519s

real    0m0.199s
user    0m0.001s
sys     0m0.019s

# EXT2 without 'sync'
$ time cp backup.tar.gz /media/KINGSTON/; time umount /media/KINGSTON

real    0m1.054s
user    0m0.011s
sys     0m0.170s

real    1m23.510s
user    0m0.000s
sys     0m0.031s

This was tested on a 2.6.12-1.1378_FC3 kernel, Intel 82801DB USB2 EHCI
Controller (ehci_hcd). It might be interesting to do similar tests on some
non-USB hardware (e.g. floppies).
Comment 21 Paolo Prandini 2005-11-19 07:53:18 EST
2.6.12-1.1381_FC3smp here.
Fernando fix was useful. 
Not only now it works but it's even speedier than with 2.6.11 kernel.
Just for info I have compiled a 2.6.14.2 vanilla kernel with no success.
Only Fernando's fix was the key.
Comment 22 Matthew Miller 2006-07-10 17:43:55 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 23 petrosyan 2008-02-12 01:34:19 EST
Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

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