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
