Re: scsipi: physio split the request

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

On Thu, Dec 27, 2018 at 09:07:41AM +0000, Emmanuel Dreyfus wrote:
> Hello
> 
> A few years ago I made a failed attempt at running LTFS on a LTO 6 drive. 
> I resumed the effort, and once I got the LTFS code ported, running 
> a command like mkltfs fails with kernel console saying:
> st0(mpii0:0:2:0): physio split the request.. cannot proceed
> 
> This is netbsd-current from yesterday.

You really need tls-maxphys.  It won't be a ton of fun to rebase it
on newer NetBSD-current but it can't be more than a day's work (IIRC
where I left it we were pre device/softc cleanup, and that'll be some
nuisance to address if so).

tls-maxphys propagates the maximum supported transfer size down the
system's actual discovered bus topology at boot time; any node in the
tree can enforce its own restrictions as it sees fit, and nodes like
RAIDframe that effectively demux I/O can compute and declare their
own supported maximum.

The work remaining to be done on the branch, as I see it, is:

1) *Some* backpressure mechanism *must* be implemented to prevent
   the filesystems from greedily attempting maximum size I/Os at
   all times, because with a new, much larger maximum in many
   cases, this will lead to much worse unfairness than we now see
   (and some threads doing I/O will much more obviously starve
   others).

   IIRC we've already got something effective for either read or
   write but not the other but it's been a while, so I could be wrong.

2) There's an ugly case with RAIDframe if a component is replaced with one
   that supports a smaller maxphys.  The filesystems need to be notified
   so they can change their own internal max xfer size.  I think I wrote the
   code to deal with this but it's untested.  Wants a look.

3) A number of device drivers -- particularly things in the LSI family -- will
   need to learn about newer DMA descriptor formats supported by their
   hardware in order to support transfers of reasonable size for things like
   tape drives (mpt and possibly mfi*, for example, are currently limited to
   192K because our driver only supports a very old descriptor format; this
   should be a relatively simple fix based on reading newer open-source code
   for these devices as a reference).

I believe that should be all that's needed.  I would estimate it at 5 days
of work, or perhaps a month of evenings/weekends.  I don't have that time
available now and won't in the forseeable future, but, perhaps someone reading
this does.

And of course some of you are much quicker at this stuff than I am (thorpej,
I'm looking at you ;-)).

Most of what the branch does is useful *even if* we remove the stupid VA/PA
mapping business for I/O, I think.  Because it's mostly config sugar to let
the clients know how big an I/O they can ask for at runtime, and that will
be needed regardless.

Thor