On Tue, Jun 05, 2018 at 11:04:00AM +0200, David Spisla wrote: > 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. You can experiment with moving the WORM xlator in the .vol files of the bricks before upcall, just restart the brick processes after editing the config files. I can not immediately think of a reason why this would cause problems. You could send a patch that explains your need and changes the location of WORM (or upcall?) in the graph (see server_graph_table in xlators/mgmt/glusterd/src/glusterd-volgen.c). Niels > > 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
