Bug #1527
closed
extremely bad USB/msdos performance
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
Updated by dillon about 15 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
Updated by vsrinivas over 12 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.
Updated by tuxillo about 3 years ago
- Description updated (diff)
- Status changed from New to Closed
msdos(5) is being kept in sync with FreeBSD. Please reopen this issue if this is still an issue.