Hello Niels, 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.
Regards David 2018-06-05 11:44 GMT+02:00 Niels de Vos <nde...@redhat.com>: > 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 <nde...@redhat.com>: > > > > > 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@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel