[Pvfs2-developers] list-attr.sm refactored with pjmp

Phil Carns carns at mcs.anl.gov
Thu Mar 13 11:33:43 EST 2008


I needed to make some changes to list-attr.sm recently and realized that 
it probably should really be redone now that we have parallel nested 
machines available.  listattr is a server operation that retrieves 
attributes for a list of handles at once.  The old version duplicated 
logic from get-attr.sm, while the new version does a pjmp to the nested 
pvfs2_get_attr_work_sm machine instead.

There are a few advantages to this approach:

- it gives us a complete example of pjmp in trunk
- we don't have to keep listattr code in sync with getattr, since they 
now share the same core logic (listattr was already a little behind)
- the list-attr.sm source code is much smaller now
- list-attr.sm should be faster now as well, because it is capable of 
getting many trove operations queued up at once rather than iterating 
through each of the getattr's (and waiting for completion of each) in serial

I could stand some extra eyes to look at list-attr.sm and make sure the 
implementation in trunk is sane.  Here is a link if anyone wants to look 
at it online:

http://www.pvfs.org/fisheye/browse/~raw,r=1.9/PVFS/src/server/list-attr.sm

There are two goofy bits of code marked with a "TODO" comment:

- Running pvfs2_get_attr_work_sm requires setting a variety of 
undocumented parameters before launching it.  I'm not sure how to best 
clean this up (or if I should just let this slide for now).

- After the pjmp, it is a little hard to find the parent frame (which is 
useful to have before popping the other frames so that you have 
somewhere to store results).  I ended up just iterating through the 
frames looking for it, but I would like to find a nicer way to do this too.

-Phil


More information about the Pvfs2-developers mailing list