[Gluster-devel] handling open fds and graph switches

[Amar Tumballi]

> > >
> > >         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?
>
> Others,
> 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
counterparts.

Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130906/dc4079a0/attachment-0001.html>