> > The other method I can think of (not sure if it would suit your needs) > > is to use the syncop framework (see libglusterfs/src/syncop.c). > > This allows one to make a 'synchronous' glusterfs fop. inside a xlator. > > The downside is that you can only make one call at a time. This may not > > be acceptable for cluster xlators (ie, xlator with more than one child xlator). > > In the syncop framework, how much gets affected when I > use it in my xlator. Does it mean that there's only one call > at a time in the whole xlator (so the current write will stop > all other reads) or is the scope only the fop (so that within > this write, my child->fops are serial, but neighbouring reads > on my xlator will continue in other threads)? And does that > then restrict what can go above and below my xlator? I > mean that my xlator isn't a cluster xlator but I would like it > to be able to be used on top of (or underneath) a cluster > xlator, will that no longer be possible? > I've just taken a look at xlators/cluster/afr/src/pump.c for some syncop usage examples and I really like what I see there. If syncop only serialises/syncs activity that I code within a given fop of my xlator and doesn't impose serial/ sync limits on the parents or children of my xlator then this looks like the right path. I want to be sure that it won't result in a globally syncronous outcome though (like ignoring a cache xlator under mine to get a true disk read) - I just need the internals of my calls to be linear. -- Ian Latter Late night coder .. http://midnightcode.org/
