I am have USB Flash drive (size is 1Gb, filesystem VFAT). Kernel detects it as: Vendor: Kingston Model: DataTraveler II+ Rev: 1.13 It is true. When I use kernel: 2.6.11-gentoo-r11: read: 18-19 Mb/sec, write: 4.5 Mb/sec 2.6.12-gentoo-r4: read: 18-19 Mb/sec, write: 89 Kb/sec For testing I use 300 Mb file and Midnight Commander (mc-4.6.0-r14). To compile kernel version 2.6.12-r4 I use '.config' from kernel version 2.6.11- r11. Then run '# make menuconfig', enable PCI-Express support, exit with saving. '# make all modules_install install'... Also I have noticed that command '# emerge-webrsync' freeze my disk subsystem in kernel 2.6.12-r4. Reproducible: Always Steps to Reproduce: 1. cd /usr/src 2. cp ./linux-2.6.11-gentoo-r11/.config ./linux-2.6.12-gentoo-r4/ 3. rm linux &&ln -s linux-2.6.12-gentoo-r4 linux 4. cd linux 5. make menuconfig 6. enable PCI-Express, disable SMP (if enabled, but I have always disabled in both kernels) 7. exit with saving 8. make all modules_install install &&reboot &&exit 9. In grub need to select kernel (one of 2.6.11-r11 or 2.6.12-r4) 10. Login (as root for example) and run mc 11. Connect USB flash drive to the USB port 12. Wait for LED on flash drive turns off 13. mount /media/Kingston (I use HAL) 14. cd /media/Kingston 15. Need to copy big file (100 Mb or more) and look for speed Actual Results: Then I select kernel 2.6.11-r11: write speed ~4.5 Mb/sec Then I select kernel 2.6.12-r4: write speed ~89 Kb/sec Expected Results: >= 4.5 Mb/sec in both cases Portage 2.0.51.22-r1 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2. 6.11-gentoo-r11 x86_64) ================================================================= System uname: 2.6.11-gentoo-r11 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.12 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.9 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/ share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb / usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" LANG="ru_RU.UTF-8" LINGUAS="en ru" MAKEOPTS="-j2 -s" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 acpi alsa amd64 arts avi berkdb bitmap-fonts cdr crypt cups dga dts dvd dvdr dvdread encode esd fam ffmpeg foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 hal imlib ipv6 java jpeg junit kde kdeenablefinal lm_sensors lzw lzw-tiff mad motif mp3 mpeg ncurses nls nvidia ogg oggvorbis opengl pam pdflib perl png python qt quicktime readline rtc samba sdl slang ssl tcpd tiff truetype truetype-fonts type1-fonts unicode usb userlocales v4l2 vorbis xinerama xml2 xmms xpm xv xvid xvmc zlib linguas_en linguas_ru userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
My system: PS: HP Enhance 400 W CPU: AMD Athlon 64 3000+ (Socket939, core Venice, 1800MHz) M/B: MSI K8N Neo4 (NForce4 Ultra) (SiI RAM: 1024 Mb, Samsung, Dualchannel Video: Leadtek WinFast Geforce 6200 TC (PCI-E) hda: HITACHI 80 Gb (2 Mb cache) hdb: Maxtor 20 Gb hdc: IOMEGA ZIP100 hdd: NEC DVD-RW ND3520
I believe this is to do with changes to the sync option on vfat filesystems. For more info see: http://readlist.com/lists/vger.kernel.org/linux-kernel/22/111748.html In short, mounting without the sync option should speed things up. (HAL adds this option by default.)
Upstream bug. Please join in with your experiences at http://bugzilla.kernel.org/show_bug.cgi?id=4882
This is not-so-good (to say the least). I'd recommend adding a change to our HAL .fdi files now instead of waiting for upstream. I anticipate failure of a couple of my flash cards shortly...
Without the sync option, you can't really unplug without losing data
(In reply to comment #5) > Without the sync option, you can't really unplug without losing data Without the sync option you need to unmount the device first which you should probably do anyway. With the sync option you risk permanantly daming your flash media and so you'll lose all your data anyway. Not to mention the reduced performance (you get about 10% write speed compared to without the sync option). This really is not a kernel problem IMO, all they did is implement the sync option in 2.6.12 (previously the option was just ignored for vfat partitions). HAL really should not use -o sync by default.
To avoid this "bug" I change /usr/share/hal/fdi/90defaultpolicy/storage-policy. fdi: before: <merge key="volume.policy.mount_option.sync" type="bool">true</merge> after: <merge key="volume.policy.mount_option.sync" type="bool">false</merge>
Instead of modifying the default_storage_policy (which will get overwritten) try adding a separate .fdi file to the /usr/share/hal/fdi/95userpolicy/ dir. For example: ~ # ls /usr/share/hal/fdi/95userpolicy/ fat_no_sync.fdi local-ide-drives.fdi sharp-pc-mm10-cradle.fdi
Created attachment 63718 [details] HAL policy file to turn off sync for vfat/fat Add this to /usr/share/hal/fdi/95userpolicy/
*** Bug 102640 has been marked as a duplicate of this bug. ***
*** Bug 102888 has been marked as a duplicate of this bug. ***
@ Herbie Hopkins: I don't agree with people continuously saying "they just ignored the sync" in the past. I don't know who started that rumor, because they didn't, look at the code. When a filesystem is NOT marked "sync," when a file is copied to that filesystem, there is no nautilus progress bar, because there is no progress to track. In older kernels mounted WITH "sync," there most certainly was progress to track. I just wish they'd revert the damned changes. All the mainstream distros out there are forced to use the old fs/fat/*. This new code is majorly borked. The same is true of the damned alps mouse driver.
This bug should be re-opened because it is marked "resolved upstream" but the upstream (kernel) bug is marked rejected. Hence it will never get resolved upstream, and it causes evil problems for users here.
No, it is resolved, just change your fstab or the command you use to mount the drive, and it will work just as fast as before. It is not a kernel issue. That being said, people are working on making the sync functionality work not so slow, but that's being done by the kernel developers and will probably take a while.
*** Bug 134224 has been marked as a duplicate of this bug. ***
I am having huge problems in getting USB flash drives working correctly under Gentoo... insanely poor performance, plus other issues (drive gets a different ID, from /dev/sde1 changes to /dev/sdf1 and vice-versa), depending on which file-system I use and what mount options. Could you please give me the correct commands to mount a USB flash drive that has: - ntfs filesystem - fat32 filesystem - ext3 filesystem What I am interested in is to have good performance, I do not need it sync-ed, as I always un-mount it before unplugging the drive. You may also read this thread here for more details about what I've tried and what the results were.. http://forums.gentoo.org/viewtopic-p-5985979.html thanks a lot!
(In reply to comment #17) > I am having huge problems in getting USB flash drives working correctly under > Gentoo... insanely poor performance, plus other issues (drive gets a different > ID, from /dev/sde1 changes to /dev/sdf1 and vice-versa), depending on which > file-system I use and what mount options. > > Could you please give me the correct commands to mount a USB flash drive that > has: > > - ntfs filesystem > - fat32 filesystem > - ext3 filesystem > > What I am interested in is to have good performance, I do not need it sync-ed, > as I always un-mount it before unplugging the drive. > > You may also read this thread here for more details about what I've tried and > what the results were.. > http://forums.gentoo.org/viewtopic-p-5985979.html > > thanks a lot! > This bug was focused to the 'sync' option being enabled as default in HAL. If you are mounting your FAT flash drive without the 'sync' option and you are still getting slow transfer speeds, you should open a new bug report describing your problem in detail. We will keep this bug CLOSED, but feel free to open a new bug report regarding your problem. Finally, note that Gentoo's bugzilla is not a support forum, so just try to report buggy behaviors and not ask for general advice. Thanks :)
