Sam, The behavior that you describe is definitely correct, but is there any particular reason we expect downcalls/requests to be stuck for a long period of time in client-core and not be written back to the device... If they occur due to coding errors, we definitely want the schedule() in there so that we know that hung processes in "D" state are waiting for client-core to respond back.. I feel that keeping timeouts of the kernel module is clean for the non-error cases since we can push all the timeout stuff in pvfs2 client-core and the user-level libraries... If I recall correctly, In the past we have had problems where flow timeouts occur because servers were taking a long time to complete all requests.. The last thing we want is another timeout to add to the mix.. Am I missing something? thanks Murali
On 11/5/07, Sam Lang <[EMAIL PROTECTED]> wrote: > > Hi All, > > It looks like timeouts in a kmod request to the client daemon only > get a timeout if its not the first attempt, which looks to only occur > if the client deamon falls over and gets restarted. Instead of > calling schedule() in that first wait_for_downcall, why not call > schedule_timeout with some long-ish timeout that exceeds the timeouts > of the client daemon? > > I just wonder what happens to scheduled procs on downcalls if by some > coding error the client stays alive but never returns a downcall. It > looks like the process never gets woken up... > > -sam > _______________________________________________ > Pvfs2-developers mailing list > [email protected] > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers > _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
