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

[Kostik Belousov]

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@ 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100820/00b07568/attachment.pgp