<div dir="ltr"><div>Hello Niels,</div><div><br></div><div>yes, this seems to be a good idea. In a few hours I have to travel to an IT conference. So I will start to try your suggestion next week.</div><div><br></div><div>Regards</div><div>David<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-06-05 11:44 GMT+02:00 Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jun 05, 2018 at 11:04:00AM +0200, David Spisla wrote:<br>
> Hello Niels,<br>
> <br>
> thank you. Now I understand this better.<br>
> I am triggering the FOPs via syncop directly from the WORM Xlator which is<br>
> unfortunately below the upcall xlator.<br>
> I don't have a separate xlator, so I am searching for a solution which is<br>
> working inside of the WORM Xlator.<br>
> E.g. the autocommit function of the WORM Xlator is using the syncop<br>
> framework to change the atime<br>
> of a file. I don't know if there is a difference between FOPs triggered by<br>
> syncop or by clients from outside.<br>
> My guess is that there is no difference, but I am not sure.<br>
<br>
</span>You can experiment with moving the WORM xlator in the .vol files of the<br>
bricks before upcall, just restart the brick processes after editing the<br>
config files.<br>
<br>
I can not immediately think of a reason why this would cause problems.<br>
You could send a patch that explains your need and changes the location<br>
of WORM (or upcall?) in the graph (see server_graph_table in<br>
xlators/mgmt/glusterd/src/<wbr>glusterd-volgen.c).<br>
<span class="HOEnZb"><font color="#888888"><br>
Niels<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> <br>
> Regards<br>
> David<br>
> <br>
> 2018-06-05 9:51 GMT+02:00 Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>>:<br>
> <br>
> > On Mon, Jun 04, 2018 at 03:23:05PM +0200, David Spisla wrote:<br>
> > > Dear Gluster-Devels,<br>
> > ><br>
> > > I'm currently using the syncop framework to trigger certain file<br>
> > operations<br>
> > > within the Server Translators stack. At the same time, file attributes<br>
> > such<br>
> > > as file rights and timestamps are changed (atime, mtime). I noticed that<br>
> > > the md-cache does not get the changed attributes or only when the upcall<br>
> > > xlator is activated eg by a READDIR (executing " $ stat * ").<br>
> > > However, I would find it cleaner if right after triggering a file<br>
> > operation<br>
> > > by the syncop framework that would update md-cache. Is there a way to<br>
> > > programmatically do this within the Server Translators stack?<br>
> ><br>
> > Hi David,<br>
> ><br>
> > If you place your xlator above upcall, upcall should inform the clients<br>
> > about the changed attributes. In case it is below upcall, the internal<br>
> > FOPs can not be tracked by upcall.<br>
> ><br>
> > Upcall tracks all clients that have shown interest in a particular<br>
> > inode. If that inode is modified, the callback on the brick stack will<br>
> > trigger a cache-invalidation on the client. I do not think there should<br>
> > be a difference between FOPs from other clients, or locally created ones<br>
> > through the syncop framework.<br>
> ><br>
> > In case this does not help or work, provide a little more details (.vol<br>
> > file?).<br>
> ><br>
> > HTH,<br>
> > Niels<br>
> ><br>
</div></div></blockquote></div><br></div>