[Pvfs2-developers] a little help?

Walter B. Ligon III walt at clemson.edu
Tue Oct 24 17:21:01 EDT 2006


Hello again,

apparently, this code never considered that a posted op might complete, 
and so never included a specific case for it.  There is a now a specific 
  return code for that, but I don't know where to put it since I don't 
really understand the "reposting" thing.

Are one of these actions correct for a "posted" operation that has 
already completed, or do we need to add another one?  THis is from 
src/apps/kernel/linux/pvfs2-client-core.c about line 2812.

Walt

   repost_op:
     /*
       check if we need to repost the operation (in case of failure or
       inlined handling/completion)
     */
     switch(ret)
     {
         case 0:
         {
             /*
               if we've already completed the operation, just repost
               the unexp request
             */
             if (vfs_request->was_handled_inline)
             {
                 ret = repost_unexp_vfs_request(
                     vfs_request, "inlined completion");
             }
             else
             {
                 /*
                   otherwise, we've just properly posted a non-blocking
                   op; mark it as no longer a dev unexp msg and add it
                   to the ops in progress table
                 */
                 vfs_request->is_dev_unexp = 0;
                 ret = add_op_to_op_in_progress_table(vfs_request);
#if 0
                 assert(is_op_in_progress(vfs_request));
#endif
             }
         }
         break;
         case REMOUNT_PENDING:
             ret = repost_unexp_vfs_request(
                 vfs_request, "mount pending");
             break;
         case OP_IN_PROGRESS:
             ret = repost_unexp_vfs_request(
                 vfs_request, "op already in progress");
             break;
         default:
             PVFS_perror_gossip("Operation failed", ret);
             ret = repost_unexp_vfs_request(
                 vfs_request, "failure");
             break;
     }
     return ret;
}


Walter B. Ligon III wrote:
> OK, I think I figured out that the request completed without ever 
> deferring due to a cache hit, so it returned SM_ACTION_TERMINATE and the 
> client took that as an error.  I'm going to have to dig some more and 
> figure that out, but I'm not sure why the state machine status and not 
> the actual error code was returned.
> 
> Walt
> 
> Walter B. Ligon III wrote:
> 
>> Hello all - I'm debugging away in the pvfs-client.  I start everything 
>> up, do a mount, which seems to work, then do an ls, and it hangs.  In 
>> the log I can see a series of GETATTR requests going through the 
>> pvfs-client, until I get to the stuff I've copied here.  Its nearly 
>> done with a GETATTR, nothing unusual.  It finishes the "cleanup" 
>> state, and then the "set_sys_response" state (which is the last one) 
>> which terminates the state machine.  Then something unusual happens, 
>> it blurts out "Posted PVFS_SYS_GETATTR" at a place it had never done 
>> before, then "Operation failed: Device initialization failed" then 
>> appears to try to restart the request with equally bad results.  
>> Finally gives up and goes back to timer pings.  See the marked lines 
>> in the posting.  I'm trying to figure this out, but with my limited 
>> exposure to the pvfs-client I'm not clear WHAT exactly failed.
>>
>> Hoping someone has some ideas???
>>
>> Walt


-- 
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University


More information about the Pvfs2-developers mailing list