Download as PDF, PPTX
Uploaded byPranith Karampuri
Glusterfs session #4 call frame and programming model
Glusterfs uses an asynchronous programming model where each component (xlator) calls into the next using STACK_WIND, passing a callback. The next xlator performs its task and then callbacks the original using STACK_UNWIND. This non-blocking approach prevents any xlator from blocking on network operations. Key data structures like the call_frame track the asynchronous call and callback between xlators, maintaining a stack. Debugging information within frames helps track errors like frame loss or stuck operations.
Glusterfs session #4 call frame and programming model
- 1. Glusterfs Session #4 Call_frameand programming model
- 2. Scope - What isthe programming model used in gluster - Why this model is used - What are the data structures that help with implementing it
- 3. What is theprogramming model used in gluster - Glusterfs xlators use asynchronous programming model. - Each xlator calls into the other xlator using a macro called STACK_WIND giving it a callback function - The other xlator once it finishes its part callback using the callback function passed using STACK_UNWIND macro
- 4. Why this modelis used - Any xlator can’t assume what the other xlator is going to do with the fop - If the xlator(Like client xlator) does a network operation, blocking the calling xlator until response comes from server will kill performance. So non-blocking sockets are used for communication. - This forces every xlator to follow asynchronous programming model using call/callback model.
- 6. Code walkthrough - Stackwind and variants - Stack unwind and variants - C stack and gluster stack
- 7. Difference between Cstack and gluster stack struct _call_frame { call_stack_t *root; /* stack root */ call_frame_t *parent; /* previous BP */ struct list_head frames; gf_lock_t lock; void *cookie; /* unique cookie */ xlator_t *this; /* implicit object */ ret_fn_t ret; /* op_return address */ ... };
- 8. Call_frame_t continued struct _call_frame{ ... void *local; /* local variables */ glusterfs_fop_t op; int32_t complete; const char *wind_from; const char *wind_to; const char *unwind_from; const char *unwind_to; };
- 9. Stack-wind/unwind with clusterxlators - Demo that shows the importance of call-count - local is not accessed once all stack-winds are complete - Demo
- 10. Debug information inframes - What information is stored for debugging purposes - How to debug frame-loss/stuck frames using statedumps - Demo completed=0 - Demo how to look at frames and interpret
- 11.