Hi, I've hit a strange issue with a new USB storage device. (Corsair Slider X2 64GB) On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1] Reads are even faster. However on my Linux workstation the best I can get is 27 mbyte/sec, and the usual speed more like 9-10 mbyte/sec. ie. Awful. Reads aren't much better, at 37mbyte/sec. The same workstation can happily read and write very fast to other USB 3 storage devices, so I know the USB 3 ports are active. I've tested with vfat, ext4, btrfs and ntfs filesystems, plus just plain using "dd" to write to the raw device. In all cases, performance is terrible. I've played with mount options (sync, async, direct io, journal modes, etc) and it doesn't make a huge difference. I don't suppose anyone else has hit this, and might have a fix? (I'll test on an alternative Linux system tonight, with a slightly different Linux kernel and motherboard.) -Toby 1: Actual writes, not cached -- which I think is Windows default for removable storage. But tested by writing far more data than the laptop has RAM, followed by quickly selecting "Safely eject the device".
Toby Corkindale via luv-main <luv-main@luv.asn.au> writes:
Hi, I've hit a strange issue with a new USB storage device. (Corsair Slider X2 64GB)
On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1] Reads are even faster.
However on my Linux workstation the best I can get is 27 mbyte/sec, and the usual speed more like 9-10 mbyte/sec. ie. Awful. Reads aren't much better, at 37mbyte/sec.
The same workstation can happily read and write very fast to other USB 3 storage devices, so I know the USB 3 ports are active.
I've tested with vfat, ext4, btrfs and ntfs filesystems, plus just plain using "dd" to write to the raw device. In all cases, performance is terrible.
I've played with mount options (sync, async, direct io, journal modes, etc) and it doesn't make a huge difference.
I don't suppose anyone else has hit this, and might have a fix?
(I'll test on an alternative Linux system tonight, with a slightly different Linux kernel and motherboard.)
Brainstorm things to check: * remove any unnecessary components e.g. USB hubs from the environment. * does dmesg complain about it? * does it draw too much power for that port? * are other port blocks (different chipset &c) OK? e.g. front panel is often worse. * Is it DEFINITELY doing more than USB2 theoretical max? Compare the speed you get to the max speed of USB2 and USB3. (IIRC USB2.0 is 480mbps = 60MiB/s). * is power saving being auto-enabled ever time you plug in the device, by some crack-smoking udev rule? Remember to check the device *and* the internal hub. If powertop --auto is involved, remove it while testing. * is the system doing a lot of fsyncs &c at the time? this can break even unrelated filesystems IME. The place I hit it was doing a dpkg install (many many syncs) while under heavy RRD write load (random access). * faint hope, but does SMART work with the drive?
On Thu, 14 Jul 2016 at 17:17 Trent W. Buck via luv-main <luv-main@luv.asn.au> wrote:
Toby Corkindale via luv-main <luv-main@luv.asn.au> writes:
Hi, I've hit a strange issue with a new USB storage device. (Corsair Slider X2 64GB) (I'll test on an alternative Linux system tonight, with a slightly different Linux kernel and motherboard.)
Brainstorm things to check:
* remove any unnecessary components e.g. USB hubs from the environment.
* does dmesg complain about it?
No * does it draw too much power for that port?
No * are other port blocks (different chipset &c) OK?
e.g. front panel is often worse.
Seems to perform the same. * Is it DEFINITELY doing more than USB2 theoretical max?
Compare the speed you get to the max speed of USB2 and USB3. (IIRC USB2.0 is 480mbps = 60MiB/s).
I can read at nearly 100mbyte/sec, which is definitely USB3 speed.
* is power saving being auto-enabled ever time you plug in the device, by some crack-smoking udev rule? Remember to check the device *and* the internal hub. If powertop --auto is involved, remove it while testing.
powertop is not running. I'm not sure how to check the rest :/ Another fast USB stick is confirmed as working at ~60mbyte/sec in the same machines and ports though. * is the system doing a lot of fsyncs &c at the time?
this can break even unrelated filesystems IME.
Err, to some degree, yes.. both systems I've tested have had apps running, at least in the background. But this is true for a Windows system too -- there's always a whole lotta stuff going on in there.
The place I hit it was doing a dpkg install (many many syncs) while under heavy RRD write load (random access).
* faint hope, but does SMART work with the drive?
Negative. Neither does hdparm. Thanks for the suggestions though. -Toby
Toby Corkindale wrote:
* is power saving being auto-enabled ever time you plug in the device, by some crack-smoking udev rule? Remember to check the device *and* the internal hub. If powertop --auto is involved, remove it while testing.
powertop is not running. I'm not sure how to check the rest :/
Something like this: find /sys/ -xdev -path '*usb*/power/control' -exec grep -H -e ^ -e auto {} + "on" means the device is permanently powered up. "auto" means it'll turn off when idle. I'm not sure what they should be *in general*, but a couple of times I've hit problems with devices misbehaving and forcing their power from "auto" to "on" helped.
Toby Corkindale via luv-main <luv-main@luv.asn.au> writes: PS: also: if you take the working windows+hardware config and replace windows with live linux, then something like gddrescue /dev/zero /dev/sdz, does that show the same slowdown? If so that would be a strong indication the fault is with linux kernel/userland, not hardware.
On Wed, Jul 13, 2016 at 07:25:25AM +0000, Toby Corkindale via luv-main wrote:
I've hit a strange issue with a new USB storage device. (Corsair Slider X2 64GB)
On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1] Reads are even faster.
However on my Linux workstation the best I can get is 27 mbyte/sec, and the usual speed more like 9-10 mbyte/sec. ie. Awful. Reads aren't much better, at 37mbyte/sec.
does 'lsusb -t' say it's running at 5000M? eg. /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M I guess there's a chance your device has been blacklisted for not playing nicely with usb3 or something like that too. you could grep for its usb ids under /etc/udev or /usr/lib/udev. cheers, robin
Thanks for the tip. But that confirms it's running at 5000M: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M Weird, hey? It is almost like it's just not being allowed to get full speed though. I'm running Linux kernel 4.4.0 and 4.3.0 on the relevant machines. I did actually discover that initially, on one machine, I was accidentally using USB2, but after that facepalm moment and using usb3, only read speed went up -- writes still cap out at 27-28 mbyte/sec. Toby On Thu, 14 Jul 2016 at 17:44 Robin Humble via luv-main <luv-main@luv.asn.au> wrote:
On Wed, Jul 13, 2016 at 07:25:25AM +0000, Toby Corkindale via luv-main wrote:
I've hit a strange issue with a new USB storage device. (Corsair Slider X2 64GB)
On a Windows 10 laptop, it'll happily get ~75mbyte/sec writes.[1] Reads are even faster.
However on my Linux workstation the best I can get is 27 mbyte/sec, and the usual speed more like 9-10 mbyte/sec. ie. Awful. Reads aren't much better, at 37mbyte/sec.
does 'lsusb -t' say it's running at 5000M? eg.
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
I guess there's a chance your device has been blacklisted for not playing nicely with usb3 or something like that too. you could grep for its usb ids under /etc/udev or /usr/lib/udev.
cheers, robin _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
On Thu, 14 Jul 2016 at 18:59 Robin Humble via luv-main <luv-main@luv.asn.au> wrote:
On Thu, Jul 14, 2016 at 07:56:55AM +0000, Toby Corkindale wrote:
went up -- writes still cap out at 27-28 mbyte/sec.
if you dd using large blocks does that improve things? eg. dd if=/dev/zero of=<whatever> bs=8M oflag=direct
When I was first testing it, I noticed that with block sizes around, say, 10M, it went at ~8mbyte/sec. With 100+M blocks, I could hit 24 or so. -Toby
Toby Corkindale via luv-main writes:
if you dd using large blocks does that improve things? eg. dd if=/dev/zero of=<whatever> bs=8M oflag=direct
When I was first testing it, I noticed that with block sizes around, say, 10M, it went at ~8mbyte/sec. With 100+M blocks, I could hit 24 or so.
That's why I suggested GNU ddrescue - it auto-adjusts the block size for best throughput. (... I think. These days I mostly just use cp foo.iso /dev/sdb.)
On Mon, 18 Jul 2016 at 11:24 Trent W. Buck via luv-main <luv-main@luv.asn.au> wrote:
Toby Corkindale via luv-main writes:
if you dd using large blocks does that improve things? eg. dd if=/dev/zero of=<whatever> bs=8M oflag=direct
When I was first testing it, I noticed that with block sizes around, say, 10M, it went at ~8mbyte/sec. With 100+M blocks, I could hit 24 or so.
That's why I suggested GNU ddrescue - it auto-adjusts the block size for best throughput. (... I think. These days I mostly just use cp foo.iso /dev/sdb.)
And that's the thing.. all I want to do is "cp file /mnt/blah" too. And that method (cp) does report the highest throughput -- it's just that it caps out at 27 mbyte/sec. Whereas on a Windows laptop or workstation, it smashes it out at 75mbyte/sec. (And there are plenty of reviews online confirming the high speed) I guess it's just something in the Linux usb implementation sucking in some peculiar way to this Corsair stick.. :( Toby
participants (4)
-
Robin Humble -
Toby Corkindale -
Trent W. Buck -
trentbuck＠gmail.com