[Gluster-devel] Gluster internals
Ian Latter
ian.latter at midnightcode.org
Sun May 20 07:40:54 UTC 2012
> > 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/
More information about the Gluster-devel
mailing list