USB stick performance [ANSWERED]

[AS]

Hi All,

while using my USB sticks for various things, from copying files to building LiveUSB, had noticed some performance issue.

Should say that this is not new to me, and from my experience depend from the block size used to format the stick, implicitly depends from the type of filesystem used.

A large block size filesystem (FAT16, 16 Kb) generally work faster than small block size filesystem (FAT32, ext2, ext3, ext4 all using 4 Kb blocks).

I find unfortunate that ext filesystems family doesn't support blocks larger than 4 Kb, and would like to hear about similar (or different) experience and results while using USB sticks.

Thanks for feedback.

AS

[Just17]

Interesting ....

As I never use Win filesystems for my working USB drives, I cannot make any comment comparing them to Linux FSs.

What I can definitely say is that USB flash sticks which apper to have the same R/W speed specs, do not behave in a similar fashion regarding speed of booting of a LiveUSB.

So to me the big differences are in the relative performaces of the flash sticks while being prepared with the same FS, partition size, and OS.

In addition I have had some PCs of higher spec than my regular PC, boot a flash stick slower ....  and yes both USB 2 ..... so there may be a lot more in play here than at first appears 


regards.

[menotu]

Any use?

Increase USB Flash Drive Write Speed

http://linux-howto-guide.blogspot.com/2009/10/increase-usb-flash-drive-write-speed.html

The one of the biggest problems of usb flash drives is a slow data write speed. This article will guide you through the process that can possibly increase your flash stick write speed.

Okay, first I bought Transcend 8GB usb flash stick. It had been formatted with FAT32 filesystem initially. So I decided to run data read/write speed test. Mount the filesystem and execute following

# hdparm -t /dev/sdb

/dev/sdb:
Timing buffered disk reads: 102 MB in 3.05 seconds = 33.43 MB/sec

$ dd count=100 bs=1M if=/dev/urandom of=/media/disk/test
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 29.5112 s, 3.6 MB/s


The disk read speed is good enough, but the write speed is not so good. That's because most of NAND flash drives (the most commonly used flash sticks) have 128k erase block size. Filesystems usually have 4k (4096 bytes) block size. And here we came into problem. If the filesystem blocks are not aligned to flash drive blocks, the performance overhead during disk writes will increase. So what we can do is to align filesystem properly. The best way to do this is to use 224 (32*7) heads and 56 (8*7) sectors/track. This produces 12544 (256*49) sectors/cylinder, so every cylinder is 49*128k.

# fdisk -H 224 -S 56 /dev/sdb

Now turn on expert mode with fdisk and force the partition to begin on 128k alignment. In my case I have set new beginning of data to 256. Create as many partitions as you need (I created only one - /dev/sdb1).
Do not forget to save changes and write new layout to flash drive (all data on the flash disk will be lost)
Now it's time to create the filesystem. I used ext4 because there is a way to tell it to specify a strip width to keep your filesystem aligned:

# mke2fs -t ext4 -E stripe-width=32 -m 0 /dev/sdb1

Now lets mount the filesystem and test the overall performance

# hdparm -t /dev/sdb

/dev/sdb:
Timing buffered disk reads: 102 MB in 3.01 seconds = 33.94 MB/sec

$ dd count=100 bs=1M if=/dev/urandom of=/media/disk/test
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 17.0403 s, 6.2 MB/s

As we can see, the data read performance is almost the same while the write speed is considerably faster.

[Just17]

Thanks menotu ......  had forgotten about that alignment ..... I probably read it when you posted it previously 

[AS]

thanks menotu,

should be noted that the hdparm command ...

Code: [Select]

# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 102 MB in 3.01 seconds = 33.94 MB/sec
... really work on the raw device, completely unaware about the filesystem eventually used, it could be used even on a not partitioned device, this is the reason because results doesn't change depending on format.  (in fact no partition is specified ...)


Additionally, I disagree with the use of the use of /dev/urandom, notably is known to be slow, I would suggest to use /dev/zero for testing purposes... which is much faster and hopefully doesn't introduce a bottleneck by itself.

Code: [Select]

dd count=100 bs=1M if=/dev/urandom of=/media/disk/test

Actually I'm still obtaining the better write performance using FAT16 (not FAT32) ... will do some extended test about ...

AS

[AS]

Some test, using my notebook dell vostro 1710, USB 2.0, Intel(R) Core(TM)2 Duo T8100 @ 2.10GHz.

for each one identification from dmesg and performance from hdparm -t /dev/sdc:

PNY 2 Gb:

scsi 9:0:0:0: Direct-Access              USB Flash Memory 5.00 PQ: 0 ANSI: 0 CCS
sd 9:0:0:0: Attached scsi generic sg3 type 0
sd 9:0:0:0: [sdc] 4028416 512-byte logical blocks: (2.06 GB/1.92 GiB)

/dev/sdc:
 Timing buffered disk reads:  36 MB in  3.02 seconds =  11.90 MB/sec

Sandisk 4 Gb:

scsi 10:0:0:0: Direct-Access     SanDisk  Cruzer           8.02 PQ: 0 ANSI: 0 CCS
sd 10:0:0:0: Attached scsi generic sg3 type 0
sd 10:0:0:0: [sdc] 7913471 512-byte logical blocks: (4.05 GB/3.77 GiB)

/dev/sdc:
 Timing buffered disk reads:  50 MB in  3.11 seconds =  16.07 MB/sec

Verbatim 4 Gb:

scsi 11:0:0:0: Direct-Access     General  USB Flash Disk   1100 PQ: 0 ANSI: 0 CCS
sd 11:0:0:0: Attached scsi generic sg3 type 0
sd 11:0:0:0: [sdc] 7815168 512-byte logical blocks: (4.00 GB/3.72 GiB)

/dev/sdc:
 Timing buffered disk reads:  32 MB in  3.16 seconds =  10.14 MB/sec

HP 4 Gb:

scsi 12:0:0:0: Direct-Access     HP       v100w            PMAP PQ: 0 ANSI: 0 CCS
sd 12:0:0:0: Attached scsi generic sg3 type 0
sd 12:0:0:0: [sdc] 7827456 512-byte logical blocks: (4.00 GB/3.73 GiB)

/dev/sdc:
 Timing buffered disk reads:  58 MB in  3.10 seconds =  18.69 MB/sec

Trascend 2 Gb;

scsi 13:0:0:0: Direct-Access     JetFlash TS2GJFV30        8.07 PQ: 0 ANSI: 2
sd 13:0:0:0: Attached scsi generic sg3 type 0
sd 13:0:0:0: [sdc] 4014078 512-byte logical blocks: (2.05 GB/1.91 GiB)

/dev/sdc:
 Timing buffered disk reads:  34 MB in  3.06 seconds =  11.10 MB/sec

Kingston datatravelr 2 Gb:

scsi 14:0:0:0: Direct-Access     Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
sd 14:0:0:0: Attached scsi generic sg3 type 0
sd 14:0:0:0: [sdc] 3966976 512-byte logical blocks: (2.03 GB/1.89 GiB)

/dev/sdc:
 Timing buffered disk reads:  60 MB in  3.02 seconds =  19.89 MB/sec

Kingston datatraveler3G 8 Gb:

scsi 15:0:0:0: Direct-Access     Kingston DataTraveler G3  PMAP PQ: 0 ANSI: 0 CCS
sd 15:0:0:0: Attached scsi generic sg3 type 0
sd 15:0:0:0: [sdc] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)

/dev/sdc:
 Timing buffered disk reads:  64 MB in  3.09 seconds =  20.73 MB/sec

... to be continued

[Just17]

One of my drives ...... a 16GB relatively new drive - Corsair Voyager

scsi 14:0:0:0: Direct-Access     Corsair  Voyager          1100 PQ: 0 ANSI: 0 CCS
sd 14:0:0:0: Attached scsi generic sg11 type 0
sd 14:0:0:0: [sdi] 31326208 512-byte logical blocks: (16.0 GB/14.9 GiB)



hdparm -t /dev/sdi

/dev/sdi:
 Timing buffered disk reads:  86 MB in  3.03 seconds =  28.42 MB/sec

and an older cheap drive .... 4GB marked "Super Talent"

scsi 15:0:0:0: Direct-Access     Flash    Drive AU_USB20   8.07 PQ: 0 ANSI: 2
sd 15:0:0:0: Attached scsi generic sg11 type 0
sd 15:0:0:0: [sdi] 8085504 512-byte logical blocks: (4.13 GB/3.85 GiB)



hdparm -t /dev/sdi

/dev/sdi:
 Timing buffered disk reads:  88 MB in  3.01 seconds =  29.24 MB/sec

[AS]

that's explain why I'm suffering USB performance 

[Just17]

that's explain why I'm suffering USB performance 

[pags]

Additionally, I disagree with the use of the use of /dev/urandom, notably is known to be slow, I would suggest to use /dev/zero for testing purposes... which is much faster and hopefully doesn't introduce a bottleneck by itself.

Code: [Select]

dd count=100 bs=1M if=/dev/urandom of=/media/disk/test

I think the idea of using /dev/urandom is to prevent any read-optimization or caching from impacting the test (forcing the data to go the device).  By that same argument, however, maybe

Code: [Select]

dd count=100 bs=1m if=/media/disk/test of=/dev/null
after the write from /dev/urandom to test the read speed...

[djohnston]

Well, you guys have pretty well covered the read/write testing. If it's bigger blocksizes you're after, you might try experimenting with xfs. You can specify blocksizes from 512 bytes up to 64K.

[AS]

Additionally, I disagree with the use of the use of /dev/urandom, notably is known to be slow, I would suggest to use /dev/zero for testing purposes... which is much faster and hopefully doesn't introduce a bottleneck by itself.

Code: [Select]

dd count=100 bs=1M if=/dev/urandom of=/media/disk/test

I think the idea of using /dev/urandom is to prevent any read-optimization or caching from impacting the test (forcing the data to go the device).  By that same argument, however, maybe

Code: [Select]

dd count=100 bs=1m if=/media/disk/test of=/dev/null
after the write from /dev/urandom to test the read speed...

Several things are wrong with the above test, the worse is that using dd to write a file doesn't prevent the system to use the buffers: what happens is that the write instructions appear to be completed while the written content still  need to be flushed out. In fact here there is some ridiculous result:

# dd bs=1M count=64 if=/dev/zero of=/mnt/test
64+0 records in
64+0 records out
67108864 bytes (67 MB) copied, 0.0850779 s, 789 MB/s

About the cache, the kernel never look at data content, only at data block address(es), a data block is cached when the address block is found in cache, no matter what's the content of the block.

Well, you guys have pretty well covered the read/write testing. If it's bigger blocksizes you're after, you might try experimenting with xfs. You can specify blocksizes from 512 bytes up to 64K.

I tried this:

# mkfs.xfs -f -b size=16384 /dev/sdc1
meta-data=/dev/sdc1              isize=256    agcount=4, agsize=30973 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=16384  blocks=123891, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=16384  ascii-ci=0
log      =internal log           bsize=16384  blocks=1000, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=16384  blocks=0, rtextents=0

but, when trying to mount the partition:

# mount -t xfs /dev/sdc1 /mnt
mount: Function not implemented

[JALU]

This might be of interest>

offer XFS as a choice of filesystem, but few of these let the user create XFS for the /boot filesystems due to deficiencies and unpredictable behavior in GRUB, often the default bootloader.[1] FreeBSD gained read-only support for XFS in December 2005 and in June 2006 experimental write support was introduced; however this is supposed to be used only as an aid in migration from Linux, not to be used as a "main" filesystem.

http://en.wikipedia.org/wiki/XFS
Not necessarily true - the wiki may be a little aged... 

[Just17]

but, when trying to mount the partition:
Quote
# mount -t xfs /dev/sdc1 /mnt
mount: Function not implemented

Mount point?

/mnt/where?

[AS]

@darkages,
thanks for info! 

@Just19,
no, it's not the mount point because it's working fine for other filesystems,actually I'm obtaining the same error also when using other filesystem types formatted with block greater than 4096

I'm going to write my own test program later on