Re: physio split the request.. cannot proceed

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Dec 23, 2013 at 02:41:29PM +0000, Emmanuel Dreyfus wrote:
> On Mon, Dec 23, 2013 at 09:23:09AM -0500, Thor Lancelot Simon wrote:
> > > I adjusted the function that detects tape block size so that it is 
> > > capped to MAXPHYS. I also fixed the debug message so that I get the
> > The resulting performance will leave much to be desired...
> 
> I can imagine that. But it is better than a failure, and ir let me 
> me make progress without wiating for your branch to be merged.

To be clear, using small blocks on modern tapes will probably lead to
a dramatic reduction in tape capacity, not just read and write speed.
Tapes can get very, very expensive, so a warning seemed to be in order!

For what it's worth, I've been *very* busy, but there's not actually much
left to do on the maxphys branch -- one mechanical task (resync it with head)
and a few head-scratchers:

1) What to do when a disk's maxphys becomes smaller?  This can happen with
   virtual-disk devices like LVM or RAIDframe when a component is attached
   on a new bus.  The simplest thing to do is to disallow such attaches.

2) Our read-ahead and write-behind logic needs to become smarter so it does
   not aggressively issue MAXPHYS sized I/Os unless a true sequential read
   or write pattern is detected!

3) A number of SCSI controller drivers (generally for RAID devices
   implementing SCSI target on the controller itself) like arcmsr
   are miscoded such that they cannot expose the optimal transfer
   size for a disk until well _after_ it's attached.  These need to be
   reworked so that they do whatever look-aside they need to in order to
   discover the right transfer size (in arcmsr's case, this means matching
   the 'scsi disk' with a RAID volume in a separate datastructure) before
   telling NetBSD the target is there.

4) Most ports won't benefit until they get MACHINE_MAXPHYS increased and
   their bus drivers adjusted appropriately.

I actually think it would be appropriate to merge the branch to -current
with only #1 fixed, and at least a strategy in mind for dealing with #2.
It's just that there's a fairly extensive literature on #2, and I haven't
had time to read it!

Thor