Re: umass(4)/uhci(4) REALLY slow

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