<div dir="ltr"><div>Hello Niels,</div><div><br></div><div>thank you. Now I understand this better.<br></div><div>I am triggering the FOPs via syncop directly from the WORM Xlator which is unfortunately below the upcall xlator.</div><div>I don't have a separate xlator, so I am searching for a solution which is working inside of the WORM Xlator.</div><div>E.g. the autocommit function of the WORM Xlator is using the syncop framework to change the atime</div><div>of a file. I don't know if there is a difference between FOPs triggered by syncop or by clients from outside.</div><div>My guess is that there is no difference, but I am not sure.</div><div><br></div><div>Regards</div><div>David<br></div><div><div class="gmail_extra"><br><div class="gmail_quote">2018-06-05 9:51 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 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 operations<br>
> within the Server Translators stack. At the same time, file attributes 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 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>
</span>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>
</blockquote></div><br></div></div></div>