1

I've got Scientific Linux 6.4 Installed (RHEL6.4) and am having trouble transferring to and from USB flash drives...

Transfer seems to hang multiple times during transfer to the device, and transfer from the device is slower than it should be (500kb/s), I think this is due to multiple hangs during this transfer too.

After quite a bit of googling I'm suspicious of this Memory Management Problem. I'm a bit dubious of the patch suggested as it may be worse than the original problem (see linked article in memory management problem).

Also, It seems this problem has been solved in a later kernel as show here. My current kernel version is 2.6.32-358.23.2.el6.x86_64. I'm not sure whether I should manually upgrade the kernel, having never done this before and I guess that a lot of the dependencies would also need upgrading from source too.

I didn't have this problem in version RHEL5 and rather than perform a fresh install, would like to fix this in 6.4. Let me know if you need more info.

Community
  • 1
mogthesprog
  • 21
  • 2
  • 1
    What kind of filesystem is on the USB flash drive? This behaviour is well-known for NTFS… Try, whether the same happens, if you use another FS like ext4 on the USB flash drive. – Elias Probst Nov 30 '13 at 15:06
  • I've tried axt4 NTFS and FAT32, none of which seem to solve the problem. It's cutrrently formated to FAT32 and copying to the same drive on MacOS and Windows7 works perfectly. – mogthesprog Nov 30 '13 at 18:34
  • updated kernel using the epelrepo-kernel repository to the kernel-lt, and i still have the same problem. the current kernel-lt is 3.10.20-1.el6.elrepo.x86_64, not sure if it's worth trying the kernel-ml package... It's probably worth noting that after completely fresh install of RHEL6.4 the problem remains the same. – mogthesprog Dec 01 '13 at 13:42
  • Try to unload the USB 1.0 and USB 2.0 modules and only keep the USB 3.0 modules loaded. If you only have USB 2.0, unload the 1.0 modules and keep the 2.0. – Elias Probst Dec 01 '13 at 14:21
  • @EliasProbst I'm not entirley sure how to unload the modules. `lsmod | grep ` where usb module is either ehci-hcd or uhci-hcd just returns nothing. It seems that the modules are compiled into the kernel. As seen in `/boot/config($uname -r) | grep `. The structure of the config file in boot is that if =y then compile into kernel or if =m then plugin as module. I understand the output of this file, what i'm not sure about is whether i can just change these lines of code to an "m" and then they will be loaded as modules so i can manipulate then with modprobe. – mogthesprog Dec 04 '13 at 13:36
  • also, sorry for convoluted answer, only so much space. I hope you understand what i mean. A weird thing happens while i'm transferring... for example i'm transferring 4 x 300mb files. the transfer will hop to 300mb (the end of the first file) almost instantly and then hang there for a while. the odd thing is it's not as if it's transferring with usb 1.1 speeds because this hang can be for a minute or two, or tens of minutes. – mogthesprog Dec 04 '13 at 13:39
  • okay, one last thing. I've been playing with strace today, and outputting only the write's. it seems that it stops writing to the USB stick intermittently for differing amounts of time, ranging from 5-10 secs to 2 mins... this problem is slowly driving me spare. – mogthesprog Dec 04 '13 at 14:37
  • You could use `latencytop` to find out more about the bottleneck. – Elias Probst Dec 04 '13 at 17:18
  • cheers for the advice, no latency top in the regular kernel so i had to install kernel-debug and kernel-debug-devel... plot twist, no copying problem in kernel-debug. There must be loads of differences between the kernel itself. However, one stood out like a sore thumb - usb sticks aren't automounted in debug. so i had to manually mount the usb stick. I've just had a quick check but i can't find the defaults for mount in kernel-debug. but, there must be a difference... maybe the -sync option? – mogthesprog Dec 04 '13 at 19:47
  • Yes, the 'sync' option is a big performance killer. If you're in full control of the connected USB device, use 'async' (should actually be default) if possible. – Elias Probst Dec 04 '13 at 20:15
  • @EliasProbst Just mounted with the async option, i'm not sure what the default is (neither sync nor async is shown in /proc/mounts) but sync improves on the problem. Now i have an issue where everything seems to be written to the drive at dismount... which is a little bit inconvenient. Thanks for all your time by the way. – mogthesprog Dec 04 '13 at 22:01
  • @EliasProbst Hi, after a bit more fiddling, i've found the culprit. It seems the flush option of vfat is what's causing the problem. I have no idea how to change the defaults for automounting usb sticks... any ideas? – mogthesprog Dec 04 '13 at 22:08
  • @EliasProbst How do i close this as answered now that i've posted the answer, also how do i give you credit? Cheers! – mogthesprog Dec 10 '13 at 12:45

1 Answers1

1

Okay, just in case someone else seems to stumble upon this question with the same problem...

The culprit is both the 'flush' and 'sync' options on the mount command for FAT32 disks. removing these and using mount <device> <mnt-point> -o (options),async instead fixes the problem. I'm not sure whether this is a bug in the FAT module mounting module.

The memory-managment issues are not a problem in RHEL6.4...

Also, if anyone knows how i can give credit for reaching this response to @EliasProbst, that'd be great.

Marking this answered for posterity.

mogthesprog
  • 21
  • 2