[Gluster-devel] handling open fds and graph switches
amarts at gmail.com
Fri Sep 6 07:28:11 UTC 2013
> > >
> > > Introduce a key in xdata "force-open" in open fop and if that
> > > key is set, make open-behind to not to delay open.
> > >
> > > But the problem is syncop_open () does not send any dictionary (it
> > > will be NULL). We can make open-behind
> > > check whether xdata is NULL and if so, consider that open call be
> > > generated internally (not from application) and wind it to the
> > > below xlator.
> > >
> > >
> > > Hmm.. I am not too sure whether we can rely on the interpretation that
> > > xdata being NULL means to force open in open-behind. There definitely
> > > are/will be other use-cases of syncop-open where some might
> > > inadvertently leave xdata NULL. It always helps in terms of
> > > understandability, to be explicit on what we want to do. Can't you
> > > create an xdata in fuse fd migration code and pass that down to
> > > syncop-open?
> > Whoever calls syncop_open does not send the xdata as the arugement at
> > all. It will be like this.
> > ret = syncop_open (new_subvol, &loc, flags, newfd);
> > The syncop framework itself sends the xdata as NULL while winding the
> > call (making syncop framework allocate a new dict before winding and
> > send it as an argument also wont work in this case, as fuse wont be able
> > to set any new key).
> Since syncops are synchronous counterparts of asynchronous fops, I think
> we can add an xdata as the argument. How about adding an xdata argument to
> syncops just the way each fop does?
> Do you've any comments or reservations on this?
I too think adding (xdata_req, &xdata_rsp) argument to all the syncops is
a good idea. That way it will be more closer to the xlator->fops
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel