Re: Gluster internals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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/



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux