Just a quick note to call people's attention to http://marc-abramowitz.com/archives/2007/02/17/getting-good-performance-out-.... This is a couple of years old but it worked like a charm for me.
Briefly, there's a kernel parameter called /sys/block/sd[a,b,...]/device/max_sectors (for USB drives sda, sdb etc.). This specifies the maximum size of a disk I/O operation for USB storage devices in units of 512 bytes, the default value being 240, i.e. 120KB (see http://www.linux-usb.org/FAQ.html#i5). The max_sectors value can be changed doing "echo N > ..." as root, and can have a dramatic effect on write performance for USB devices such as pendrives.
I tested this by writing over 2GB to a fresh VFAT filesystem on a 4GB Kingston Data Traveller pendrive plugged into a USB2 port with the EHCI driver (as indicated by dmesg). With the default setting, this took nearly 90 minutes including a final sync to flush the buffers. Using a max_sectors value of 1024 -- the highest the system would accept -- the time was reduced to under 16 minutes, a better than 5 times speedup. YMMV of course, as different brands of pendrive can have very different performance characteristics.
Note that the value resets to the default when you unplug the drive, so you need to set it manually each time. I don't know if there's a way to do this automatically, or change the default value permanently.
Sorry of everyone already knew this, but I found it so useful I just had to share it :-)
poc
On Sat, Aug 29, 2009 at 10:22 PM, Patrick O'Callaghan <pocallaghan@gmail.com
wrote:
Just a quick note to call people's attention to
http://marc-abramowitz.com/archives/2007/02/17/getting-good-performance-out-.... This is a couple of years old but it worked like a charm for me.
Briefly, there's a kernel parameter called /sys/block/sd[a,b,...]/device/max_sectors (for USB drives sda, sdb etc.). This specifies the maximum size of a disk I/O operation for USB storage devices in units of 512 bytes, the default value being 240, i.e. 120KB (see http://www.linux-usb.org/FAQ.html#i5). The max_sectors value can be changed doing "echo N > ..." as root, and can have a dramatic effect on write performance for USB devices such as pendrives.
I tested this by writing over 2GB to a fresh VFAT filesystem on a 4GB Kingston Data Traveller pendrive plugged into a USB2 port with the EHCI driver (as indicated by dmesg). With the default setting, this took nearly 90 minutes including a final sync to flush the buffers. Using a max_sectors value of 1024 -- the highest the system would accept -- the time was reduced to under 16 minutes, a better than 5 times speedup. YMMV of course, as different brands of pendrive can have very different performance characteristics.
Note that the value resets to the default when you unplug the drive, so you need to set it manually each time. I don't know if there's a way to do this automatically, or change the default value permanently.http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
There are probably other ways, but you could create a udev rule to run a shell script to set the value each time your particular device was plugged:
http://reactivated.net/writing_udev_rules.html#external-run
HTH,
On Sat, 2009-08-29 at 22:49 -0600, Jake Peavy wrote:
Note that the value resets to the default when you unplug the drive,
so
you need to set it manually each time. I don't know if there's a way
to
do this automatically, or change the default value
permanently.http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
There are probably other ways, but you could create a udev rule to run a shell script to set the value each time your particular device was plugged:
True. I'll take look. I plead lateness of the hour for not thinking of this for myself :-)
poc
On Sat, Aug 29, 2009 at 11:52:48PM -0430, Patrick O'Callaghan wrote:
Just a quick note to call people's attention to http://marc-abramowitz.com/archives/2007/02/17/getting-good-performance-out-.... This is a couple of years old but it worked like a charm for me.
Briefly, there's a kernel parameter called /sys/block/sd[a,b,...]/device/max_sectors (for USB drives sda, sdb etc.). This specifies the maximum size of a disk I/O operation for USB storage devices in units of 512 bytes, the default value being 240, i.e. 120KB (see http://www.linux-usb.org/FAQ.html#i5). The max_sectors value can be changed doing "echo N > ..." as root, and can have a dramatic effect on write performance for USB devices such as pendrives.
I tested this by writing over 2GB to a fresh VFAT filesystem on a 4GB Kingston Data Traveller pendrive plugged into a USB2 port with the EHCI driver (as indicated by dmesg). With the default setting, this took nearly 90 minutes including a final sync to flush the buffers. Using a max_sectors value of 1024 -- the highest the system would accept -- the time was reduced to under 16 minutes, a better than 5 times speedup. YMMV of course, as different brands of pendrive can have very different performance characteristics.
Note that the value resets to the default when you unplug the drive, so you need to set it manually each time. I don't know if there's a way to do this automatically, or change the default value permanently.
Sorry of everyone already knew this, but I found it so useful I just had to share it :-)
No, I didn't know it!
I was just playing with it on F12 on my eeepc 901, using a 1 gig Memorex stick. On that hardware I cannot use any value > 1024, or I get:
bash: echo: write error: Invalid argument.
but copying a 640 meg file takes abouty 4:20 (4 mins, 20 sec) with the default setting of 240 and about 40 seconds with it set to 1024. Nice speedup.
With an 8 gig Sandisk Cruzer I get the same error when trying to use a value > 1024, so it's not caused by the USB stick, but by some limitation in the system (despite what it says in the USB FAQ referenced above about there being no kernel limit.)
On Sun, 2009-08-30 at 14:40 -0400, fred smith wrote:
On Sat, Aug 29, 2009 at 11:52:48PM -0430, Patrick O'Callaghan wrote:
Just a quick note to call people's attention to http://marc-abramowitz.com/archives/2007/02/17/getting-good-performance-out-.... This is a couple of years old but it worked like a charm for me.
Briefly, there's a kernel parameter called /sys/block/sd[a,b,...]/device/max_sectors (for USB drives sda, sdb etc.). This specifies the maximum size of a disk I/O operation for USB storage devices in units of 512 bytes, the default value being 240, i.e. 120KB (see http://www.linux-usb.org/FAQ.html#i5). The max_sectors value can be changed doing "echo N > ..." as root, and can have a dramatic effect on write performance for USB devices such as pendrives.
I tested this by writing over 2GB to a fresh VFAT filesystem on a 4GB Kingston Data Traveller pendrive plugged into a USB2 port with the EHCI driver (as indicated by dmesg). With the default setting, this took nearly 90 minutes including a final sync to flush the buffers. Using a max_sectors value of 1024 -- the highest the system would accept -- the time was reduced to under 16 minutes, a better than 5 times speedup. YMMV of course, as different brands of pendrive can have very different performance characteristics.
Note that the value resets to the default when you unplug the drive, so you need to set it manually each time. I don't know if there's a way to do this automatically, or change the default value permanently.
Sorry of everyone already knew this, but I found it so useful I just had to share it :-)
No, I didn't know it!
I was just playing with it on F12 on my eeepc 901, using a 1 gig Memorex stick. On that hardware I cannot use any value > 1024, or I get:
bash: echo: write error: Invalid argument.
but copying a 640 meg file takes abouty 4:20 (4 mins, 20 sec) with the default setting of 240 and about 40 seconds with it set to 1024. Nice speedup.
With an 8 gig Sandisk Cruzer I get the same error when trying to use a value > 1024, so it's not caused by the USB stick, but by some limitation in the system (despite what it says in the USB FAQ referenced above about there being no kernel limit.)
It turns out that the FAQ is wrong. Perhaps it's out of date. In /usr/share/doc/kernel-doc-2.6.30.5/Documentation/block/biodoc.txt we find: "The upper limit of max_sectors is 1024."
poc
Patrick O'Callaghan wrote:
Just a quick note to call people's attention to http://marc-abramowitz.com/archives/2007/02/17/getting-good-performance-out-.... This is a couple of years old but it worked like a charm for me.
Briefly, there's a kernel parameter called /sys/block/sd[a,b,...]/device/max_sectors (for USB drives sda, sdb etc.). This specifies the maximum size of a disk I/O operation for USB storage devices in units of 512 bytes, the default value being 240, i.e. 120KB (see http://www.linux-usb.org/FAQ.html#i5). The max_sectors value can be changed doing "echo N > ..." as root, and can have a dramatic effect on write performance for USB devices such as pendrives.
I tested this by writing over 2GB to a fresh VFAT filesystem on a 4GB Kingston Data Traveller pendrive plugged into a USB2 port with the EHCI driver (as indicated by dmesg). With the default setting, this took nearly 90 minutes including a final sync to flush the buffers. Using a max_sectors value of 1024 -- the highest the system would accept -- the time was reduced to under 16 minutes, a better than 5 times speedup. YMMV of course, as different brands of pendrive can have very different performance characteristics.
This has been discussed in other groups, and the issue seems to be that a write to flash time is described as a constant value plus a size dependent value, and that by doing fewer and larger writes the penalty of the constant is less, since it is incurred less often.
Note that the value resets to the default when you unplug the drive, so you need to set it manually each time. I don't know if there's a way to do this automatically, or change the default value permanently.
Sorry of everyone already knew this, but I found it so useful I just had to share it :-)
I found that it made essentially no difference in read speed (4300k/s vs 4400k/s) so people should be sure they note that "write" is specified in the above 1st paragraph, don't overlook it!
Didn't seem to do much for write speed on a USB connected hard drive, so the significant benefit seems limited to write to flash. That's important, but for many uses there are far more reads than writes.
HINT:I wish it were a standard feature of install to a flash drive. Manually setting it during install is probably worth trying. Any FC11 developers reading this? HINT!!
Bill Davidsen wrote:
Didn't seem to do much for write speed on a USB connected hard drive, so the significant benefit seems limited to write to flash.
It could be an interaction with the erasable-block size of the flash.
Flash doesn't like small writes, and 120KiB could be small and inefficient for a 256 KiB flash block.
I have a really slow flash (writes at 2MiB/s), so I tried to increase the number; the trick was impossible for me, the parameter is refused when >120.
On 09-08-30 20:06:22, Roberto Ragusa wrote: ...
I have a really slow flash (writes at 2MiB/s), so I tried to increase the number; the trick was impossible for me, the parameter is refused when >120.
Just out of curiosity, what happens with 64?
On Sun, 2009-08-30 at 19:10 -0400, Bill Davidsen wrote:
I found that it made essentially no difference in read speed (4300k/s vs 4400k/s) so people should be sure they note that "write" is specified in the above 1st paragraph, don't overlook it!
I was careful to say I was testing write speed, but thanks for drawing further attention to it. My specific need is to copy large files quickly to a pendrive so I don't much care about improving read speed.
Didn't seem to do much for write speed on a USB connected hard drive, so the significant benefit seems limited to write to flash. That's important, but for many uses there are far more reads than writes.
Same here. I did try it on my external USB hard drive (Iomega 500GB) but I don't notice the effect. This could be because of Flash limitations in the pendrive, but perhaps also because the hard drive has a better processor (USB is basically a specialized packet protocol and requires a cpu -- or at least a state machine -- at each end.)
HINT:I wish it were a standard feature of install to a flash drive. Manually setting it during install is probably worth trying. Any FC11 developers reading this? HINT!!
Good idea. It also couldn't hurt when the system is *running* from a Live USB stick with a persistent overlay.
poc
Tony Nelson wrote:
On 09-08-30 20:06:22, Roberto Ragusa wrote: ...
I have a really slow flash (writes at 2MiB/s), so I tried to increase the number; the trick was impossible for me, the parameter is refused when >120.
Just out of curiosity, what happens with 64?
64 or 60 appears to slow it down a bit (2.5MiB/s becomes 2.2MiB/s).
On 09-09-05 08:22:36, Roberto Ragusa wrote:
Tony Nelson wrote:
On 09-08-30 20:06:22, Roberto Ragusa wrote: ...
I have a really slow flash (writes at 2MiB/s), so I tried to increase the number; the trick was impossible for me, the parameter is refused when >120.
Just out of curiosity, what happens with 64?
64 or 60 appears to slow it down a bit (2.5MiB/s becomes 2.2MiB/s).
Thanks. So it's not just a "power of 2" issue.
I wonder if it is related to the size of an "erase" block (which I read are usually 64K, 128K, or 256K)? When writing is slow, there may be lots of read/alter/rewrites happening, with extra wear on the flash.
-
Bill Davidsen -
Fred Smith -
Jake Peavy -
Patrick O'Callaghan -
Roberto Ragusa -
Tony Nelson