Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

On Friday, August 20, 2010 3:42:27 pm Kostik Belousov wrote:
> On Fri, Aug 20, 2010 at 03:35:48PM -0400, John Baldwin wrote:
> > On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote:
> > > It seems nobody replied to the mdf_at_ objection against wait of the
> > > new proc startup being equivalent to the LOR. I think that the wait
> > > is safe, because the task is executed in the context of
> > > the different process then the enqueue request.
> > > This might be worth noting in the comment or commit message.
> > 
> > I do wonder if we could get away with not waiting at all and always return -1?
> > You could have the task handler actually finish the toggle of the tristate in
> > the array.  Potentially you could even dispense with the linked list of
> > malloc'd structures and just walk the array creating processes for any entries
> > in the "in-progress" state in the task handler.  You might also want to avoid
> > submitting entries for new threads if there is already a pending one?  If that
> > is the case it could be further simplified by having the task always create a
> > single kthread when scheduled and just scheduling the task anytime a request
> > needs one.
> I think this is not that easy. Please take a look at nfs_asyncio().
> There is a lot of logic what to do in case an nfsiod thread was found
> or not etc.

Gah, the real problem is that unless the new kproc starts up super fast we
would invariably return EIO causing the I/O to be performed synchronously more
often.  Given that, I think pluknet's patch is fine once it is updated for the
module unload case.

-- 
John Baldwin