tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: scsipi: physio split the request
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
Home |
Main Index |
Thread Index |
Old Index