Also, if this works for mps it should go into mpr as well.

Yes, I saw Harry's emails. So, I'll need to do some of my own testing here to make sure things work at shutdown without a panic. I also saw that the lock changes did not work for Harry, so I'll need to look into that some more.

I'm not sure there is a better way to update my changes without checking them in first, which I didn't do. So, the changes I made from the original review are:

Looks good Scott. I like it.

Looks good to me. Thanks!

Went ahead and added mpr changes for this to the same review. There are only slight differences between how the mps and mpr drivers handle the max I/O calculation.

Adding mps.4 man page changes to the review.

Rewrote a little to use a new sysctl variable (max_io_pages). This is the max number of pages that a user wants to use per I/O. The driver will use the lesser of this new value and the calculated value from IOCFacts. The default for max_io_pages is -1, meaning the driver will use IOCFacts.

I could default the user value to 0, which would force the driver to use the calculated value. If not 0, then use the user value. Otherwise, we don't really know what to default the value to and we're back to using a guess. Sound OK?

OK. Sure, that sounds easy enough.

Scott, do you mean to make it larger than the calculated value? If larger, there is a danger that the I/O will fail because the number of chains in the I/O could exceed the MaxChainDepth of the controller. But, the calculated value is also based on the smallest SG element allowed for every SG element (PAGE_SIZE), so the max I/O can actually be much larger than the calculated max I/O. Maybe a warning message could be printed if the user's max I/O size is larger than the calculated size. Would that work?

Yes, I can do it for mpr too, but it will be a little different due to the changes with Chain Segment Size. I just need to look at it and do the right thing.

Add back blank lines at the top of the requested functions.

Fix typo in comment.

Use FreeBSD version 1000029 instead of 1100048.

Removed duplicated define.

Updated with Warren's initial comments.

Wow. That's a lot of stuff. Who knew there could be so much wrong in such a little document :) I appreciate the feedback. I'll make the changes as suggested and put up a patch within a couple of days.

Hmmm. That's interesting. I'm not sure why I used 1100048. I made this change so that the driver would compile under 9.x as well as 10.x. I must have done some experiments and found that 1100048 was the magic number, but I'm not sure. I'll have to do some tests to see if I can use 1000029 instead. That is, I can do that if you think it's important. It's working with this change as is. Would you like me to try to figure out a version that makes more sense?