Hello there,
since I installed CentOS6 few months ago (kept up-to-date using yum), I'm facing very poor performances when writing to USB pendrives.
The hardware: a Dell Latitude E6500 laptop (Intel Core Duo P8600 @2.40Ghz), 4Go RAM + 4Go swap, several USB2 pendrives of various brands (less than old, all formatted as vfat).
When I perform a copy (with cp or midnight commander, copying big AVI files between 300Mo to 1.4Go) to those devices, whatever the source is on the same device or on another disk, I notice that the CPU activity shows 2 phases as far as I can see with the Gnome system monitor applet:
- a phase where both CPUs show less than 20% of activity, and IOWait is <80%. It lasts the time I would expect such copy to last (say, it's like writing at 1-4MB/sec to such devices, which is reasonable or expected).
- a phase, at least twice as long as 1st phase but this ratio depends on the file copy size, where CPUs show <5% of activity but IOWait is at 100%.
During phase 1, system and applications are responsive, as expected during a file copy to external USB2 disks. During phase 2, system is slow, applications are often non responsive.
I was not facing this behaviour w/ Fedora 11, not w/ the Windows XP system also installed on this laptop.
I'm not facing such poor performances when writing to externals SATA drives (thru the same USB2 ports), even formatted as vfat. Neither when writing to those pendrives from another hardware system.
`hdparm -tT` is useless here.
I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here.
BTW, I'm still unable to control the mount options that are automatically set by Gnome - even if I can mount manually if I want.
Any hint?
Regards,
From: wwp subscript@free.fr
I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here.
I guess it is to be safe in case users remove their usb keys without unmounting first...
JD
Hello John,
On Tue, 10 Jan 2012 08:57:14 -0800 (PST) John Doe jdmls@yahoo.com wrote:
From: wwp subscript@free.fr
I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here.
I guess it is to be safe in case users remove their usb keys without unmounting first...
OK, meaning no write-cache for those devices, makes sense in some way. But this doesn't explain the main issue I reported, although I didn't find a way to change the default mount options used by Gnome (gconf settings don't match those that are used).
Regards,
On 01/11/2012 08:45 AM, wwp wrote:
Hello John,
On Tue, 10 Jan 2012 08:57:14 -0800 (PST) John Doejdmls@yahoo.com wrote:
From: wwpsubscript@free.fr
I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here.
I guess it is to be safe in case users remove their usb keys without unmounting first...
OK, meaning no write-cache for those devices, makes sense in some way. But this doesn't explain the main issue I reported, although I didn't find a way to change the default mount options used by Gnome (gconf settings don't match those that are used).
Do you have ehci_hcd module running?
Do you have any error messages in dmesg after you plug it in?
Hello Ljubomir,
On Wed, 11 Jan 2012 16:31:43 +0100 Ljubomir Ljubojevic office@plnet.rs wrote:
On 01/11/2012 08:45 AM, wwp wrote:
Hello John,
On Tue, 10 Jan 2012 08:57:14 -0800 (PST) John Doejdmls@yahoo.com wrote:
From: wwpsubscript@free.fr
I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here.
I guess it is to be safe in case users remove their usb keys without unmounting first...
OK, meaning no write-cache for those devices, makes sense in some way. But this doesn't explain the main issue I reported, although I didn't find a way to change the default mount options used by Gnome (gconf settings don't match those that are used).
Do you have ehci_hcd module running?
Do you have any error messages in dmesg after you plug it in?
ehci_hcd does manage my devices (it's not a loadable module, apparently compiled in kernel instead), see for instance:
kernel: usb 2-2: new high speed USB device using ehci_hcd and address 28 kernel: usb 2-2: New USB device found, idVendor=18a5, idProduct=0300 kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-2: Product: STORE N GO kernel: usb 2-2: Manufacturer: Verbatim kernel: usb 2-2: SerialNumber: 25LHXEWIZ5IZKSO0 kernel: usb 2-2: configuration #1 chosen from 1 choice kernel: scsi26 : SCSI emulation for USB Mass Storage devices kernel: scsi 26:0:0:0: Direct-Access Verbatim STORE N GO 1100 PQ: 0 ANSI: 0 CCS kernel: sd 26:0:0:0: Attached scsi generic sg4 type 0 kernel: sd 26:0:0:0: [sdd] 31506432 512-byte logical blocks: (16.1 GB/15.0 GiB) kernel: sd 26:0:0:0: [sdd] Write Protect is off kernel: sd 26:0:0:0: [sdd] Assuming drive cache: write through kernel: sd 26:0:0:0: [sdd] Assuming drive cache: write through kernel: sdd: sdd1 kernel: sd 26:0:0:0: [sdd] Assuming drive cache: write through kernel: sd 26:0:0:0: [sdd] Attached SCSI removable disk
No error AFAICS.
Regards,
On Tuesday 10 January 2012 16:17:54 wwp wrote:
Hello there,
since I installed CentOS6 few months ago (kept up-to-date using yum), I'm facing very poor performances when writing to USB pendrives.
The hardware: a Dell Latitude E6500 laptop (Intel Core Duo P8600 @2.40Ghz), 4Go RAM + 4Go swap, several USB2 pendrives of various brands (less than old, all formatted as vfat).
When I perform a copy (with cp or midnight commander, copying big AVI files between 300Mo to 1.4Go) to those devices, whatever the source is on the same device or on another disk, I notice that the CPU activity shows 2 phases as far as I can see with the Gnome system monitor applet:
a phase where both CPUs show less than 20% of activity, and IOWait is <80%. It lasts the time I would expect such copy to last (say, it's like writing at 1-4MB/sec to such devices, which is reasonable or expected).
a phase, at least twice as long as 1st phase but this ratio depends on the file copy size, where CPUs show <5% of activity but IOWait is at 100%.
During phase 1, system and applications are responsive, as expected during a file copy to external USB2 disks. During phase 2, system is slow, applications are often non responsive.
I was not facing this behaviour w/ Fedora 11, not w/ the Windows XP system also installed on this laptop.
I'm not facing such poor performances when writing to externals SATA drives (thru the same USB2 ports), even formatted as vfat. Neither when writing to those pendrives from another hardware system.
`hdparm -tT` is useless here.
I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here.
BTW, I'm still unable to control the mount options that are automatically set by Gnome - even if I can mount manually if I want.
Any hint?
Regards,
There's been a loooong discussion in various threads in Archlinux. For example:
https://bbs.archlinux.org/viewtopic.php?id=112846
A solution could be
"echo madvise > /sys/kernel/mm/transparent_hugepage/defrag"
from:
https://bbs.archlinux.org/viewtopic.php?pid=1033648#p1033648
Because trying:
"echo never > /sys/kernel/mm/transparent_hugepage/defrag"
Might break hibernation/suspending
Notice: havent tested this things in CentOS ;)
Regards
-
John Doe -
Ljubomir Ljubojevic -
Marc Deop -
wwp