> > > > > > 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
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
