> So which part of the system needs to handle the concurrency?  Does FFS
> need to be rewhacked, or what?

It's the drivers.  Hacking FFS won't do jack.

If you've got N streams of I/O being done to the fast file system (or,
say, to a raw disk), the basic goal is to get them handled as fast as
you can, and that means getting as many of them to the underlying
hardware as possible.

Disksort may help, but it's no answer; you _need_ to send multiple
requests down to the drive at once, and that means queue tags.


Consider the case of a 4-disk 'ccd' with the drives attached to most
of NetBSD's SCSI drivers.  You'll have at most 4 I/O's outstanding
to the actual disks at any time, because ccd will dispatch the I/Os to
the lower-level driver.

Now consider the case of a 4-disk RAID0 unit that shows up as 1 LUN on
your SCSI bus.  (That's not a likely device, but it'll work for
illustration and there are devices close enough that it's good
enough).  With most of NetBSD's SCSI drivers, you'll end up with
exactly _1_ I/O outstanding to the controller -- which is an average
of 1/4 of a disk at a time.  Not very good utilitzation.

The _only_ way to solve that is to make the SCSI driver to queue
tagging.


In general, using queue tagging can only help performance (unless
you're doing something dumb like trying to use too many tags; the
number of tags supported is a drive-dependent value).  If you consider
the worst case of a drive's handling of tagged commands, it will
process them in the order received.  That's equivalent to sending them
down one at a time.  (OK, actually, if you send them down one at a
time, the extra delay in sending them to the drive may get you some
disksort() wins, but it's not clear that it would really help.)  In
the best case, the drive can optimize the handling of the requests so
that they're handled in the 'best' order.




chris