<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 15, 2019 at 6:37 AM Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The fcntl() operations are split when FUSE is used. There in direct<br>
fcntl() call that FUSE passes on, instead it calls lock() and similar<br>
interfaces. </blockquote><div><br></div><div>Sorry, I can't parse this. I think you mean "There is no (direct) fcntl(2) fop in FUSE."<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think you refer to F_GETFD and F_SETFD commands for<br></blockquote><div><br></div><div>F_GETFL and F_SETFL !<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
fcntl(). For all I can see, these do not exist in FUSE, and have not<br>
been added to gfapi either. </blockquote><div><br></div><div>Am I reading socket_connect() in rpc/rpc-transport/socket/src/socket.c correctly? It looks like we already always set O_NONBLOCK on sockets.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Not sure if the single supported flag<br>
FD_CLOEXEC can have a benefit on Gluster, as glfs_fini() is expected to<br>
cleanup everything that gfapi allocates.<br></blockquote><div><br></div><div>That presumes that the implementation always calls glfs_fini() before a call to exec(2). I guess it might be bug if it didn't. AFAIK ganesha doesn't ever call exec(2). Samba's client model is different. And it would be wrong to pass it over the wire to the server.</div><div><br></div><div>--</div><div><br></div><div>Kaleb<br></div><div> </div></div></div>