umass(4)/uhci(4) REALLY slow
Bruce Evans
bde at zeta.org.au
Wed Oct 1 21:15:29 PDT 2003
On Wed, 1 Oct 2003, Nate Lawson wrote:
> On Wed, 1 Oct 2003, Bruce Evans wrote:
> > On Tue, 30 Sep 2003, Nate Lawson wrote:
> > > Here are "iostat 5" results for my USB thumb drive on a uhci(4) controller
> > > with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly.
> > > On FreeBSD, it really lags. This is for a cp of a large file to a
> > ...
> > This is probably due to something we're not doing in msdosfs. 1K is
> > probably your msdosfs file system block size.
>
> Yes, I checked and it has a 1K block size. The flash device is 64 MB.
>
> > msdosfs is missing support
> > for clustering. None of the lower levels (buffer cache, driver, usb)
> > in FreeBSD does clustering (the buffer cache has some support for it,
> > ...
>
> What would need to be done to add msdosfs clustered reads/writes or
> perhaps do this in a more general way in the buffer cache?
Not a lot for msdosfs. Basically, add some B_CLUSTEROK's and
vfs_bio_awrite()s, and 1 cluster_write() to msdosfs_write(). Merge
them from ffs_write(). Better, merge more of ffs_write(). IIRC, using
cluster_write() is only a small optimization -- write clustering mostly
work if you throw everything into the buffer cache using bdwrite()
without neglecting to set B_CLUSTEROK. Not much more for the buffer
cache if you only do what bdwrite() and B_CLUSTEROK do. Non-delayed
writes can't be clustered very effectively at the buffer cache level.
Similarly for read clustering except it is cluster_read() and larger
read-ahead instead of cluster_write() and B_CLUSTEROK/vfs_bio_awrite()
that are needed. The file system must be more involved since reads are
less predictable than writes at the buffer cache level.
Bruce
More information about the freebsd-current
mailing list