Bug #1527

extremely bad USB/msdos performance

Added by corecode almost 5 years ago. Updated over 2 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:vsrinivas% Done:

0%

Category:-
Target version:-

Description

The performance for writing to msdosfs on an ehci usb device is
pathetic. I'm getting ~500KB/sec, while other OS can do at least 6MB.

the rsync process is most of the time in "iowait", "biows", "biord".

vmstat:
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni
sy in id
8 680 60.86 56 3.33 0.00 0 0.00 10.00 2 0.02 3 0
5 0 93
7 400 64.00 2 0.12 0.00 0 0.00 16.00 1 0.02 1 0
5 0 94
10 415 64.00 2 0.12 0.00 0 0.00 0.00 0 0.00 3 0
5 0 92
9 528 0.00 0 0.00 0.00 0 0.00 16.00 2 0.03 2 0
3 0 95
9 541 64.00 4 0.25 0.00 0 0.00 16.00 86 1.34 2 0
6 0 92
10 399 0.00 0 0.00 0.00 0 0.00 16.00 138 2.16 4 0
6 0 90
8 546 64.00 2 0.12 0.00 0 0.00 16.00 4 0.06 7 0
8 0 85
7 509 37.75 89 3.28 0.00 0 0.00 15.68 37 0.57 3 0
8 0 89
10 545 0.00 0 0.00 0.00 0 0.00 16.00 131 2.05 3 0
8 0 89
1 104 4.00 1 0.00 0.00 0 0.00 16.00 40 0.62 5 0
7 0 87
2 226 48.00 86 4.03 0.00 0 0.00 14.29 7 0.10 4 0
6 0 90
102 100 64.00 2 0.12 0.00 0 0.00 16.00 110 1.72 2 0
5 0 93
126 102 64.00 2 0.12 0.00 0 0.00 16.00 37 0.58 3 0
6 0 91
72 103 64.00 1 0.06 0.00 0 0.00 13.29 124 1.61 0 0
4 0 95
42 98 64.00 1 0.06 0.00 0 0.00 0.00 0 0.00 1 0
3 0 96
176 225 45.40 86 3.81 0.00 0 0.00 16.00 2 0.03 4 0
6 0 90
136 104 19.43 84 1.59 0.00 0 0.00 16.00 11 0.17 7 0
8 0 85
70 121 0.00 0 0.00 0.00 0 0.00 16.00 26 0.41 1 0
10 0 89
26 100 64.00 5 0.31 0.00 0 0.00 16.00 140 2.19 2 0
5 0 93
2 219 56.79 91 5.05 0.00 0 0.00 15.79 58 0.89 3 0
6 0 91

History

#1 Updated by dillon almost 5 years ago

:The performance for writing to msdosfs on an ehci usb device is
:pathetic. I'm getting ~500KB/sec, while other OS can do at least 6MB.
:
:the rsync process is most of the time in "iowait", "biows", "biord".

Try mounting it async. If that doesn't work you'd have to delve
into the filesystem code and asynchronize any synchronous bwrite()s
you see (using bdwrite()), and/or potentially change bawrite()s to
bdwrite()s.

-Matt

#2 Updated by vsrinivas over 2 years ago

  • Description updated (diff)
  • Assignee changed from 0 to vsrinivas

Confirm w/ umass on latest master.

Possible leads:
1) msdosfs does not implement runahead/behind support in BMAP, so cluster_read/cluster_write don't get a chance to cluster. FreeBSD has some changes that will help in this regard.

2) NetBSD PR/34583 has a patch to track file-end position, avoiding some chain traversals. Helps w/ write performance on long files.

3) now that device vnodes can implement cluster operations and cluster_awrite is available, msdosfs could set B_CLUSTEROK on metadata writes to devvp.

4) For a more out-there patch, msdosfs could implement double-buffering on writes; the write path would allocate a new buffer, copy data in to it, and mark it as clusterable. The new buffer would be along the device vnode rather than the file vnode. This'll allow all data&metadata to cluster, regardless of file length limits. Would incur copying costs.
(This'd be similar to HAMMER's double_buffer mode, except reflected into writes rather than reads).

5) umass may be limiting maximum clustering. This should be investigated -- in my test on master, 4KB writes seemed to be the max.

Also available in: Atom PDF