Re: [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