Hello Niels,
thank you. Now I understand this better.
I am triggering the FOPs via syncop directly from the WORM Xlator which is unfortunately below the upcall xlator.
I don't have a separate xlator, so I am searching for a solution which is working inside of the WORM Xlator.
E.g. the autocommit function of the WORM Xlator is using the syncop framework to change the atime
of a file. I don't know if there is a difference between FOPs triggered by syncop or by clients from outside.
My guess is that there is no difference, but I am not sure.
Regards
David
2018-06-05 9:51 GMT+02:00 Niels de Vos <ndevos@xxxxxxxxxx>:
On Mon, Jun 04, 2018 at 03:23:05PM +0200, David Spisla wrote:
> Dear Gluster-Devels,
>
> I'm currently using the syncop framework to trigger certain file operations
> within the Server Translators stack. At the same time, file attributes such
> as file rights and timestamps are changed (atime, mtime). I noticed that
> the md-cache does not get the changed attributes or only when the upcall
> xlator is activated eg by a READDIR (executing " $ stat * ").
> However, I would find it cleaner if right after triggering a file operation
> by the syncop framework that would update md-cache. Is there a way to
> programmatically do this within the Server Translators stack?
Hi David,
If you place your xlator above upcall, upcall should inform the clients
about the changed attributes. In case it is below upcall, the internal
FOPs can not be tracked by upcall.
Upcall tracks all clients that have shown interest in a particular
inode. If that inode is modified, the callback on the brick stack will
trigger a cache-invalidation on the client. I do not think there should
be a difference between FOPs from other clients, or locally created ones
through the syncop framework.
In case this does not help or work, provide a little more details (.vol
file?).
HTH,
Niels
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
